We have an issue with SIP to analogue convertor when used in OXO PABX system,
The thing is that as per the attached figure 1 #ext 177(analogue phone connected to SIP to analogue convertor) dials #ext 176 (IP touch 4028), then #ext 176 answers the call and transfers the call to #ext 179(analogue phone connected to SIP to analogue convertor), when #ext 177 and #ext 179 is connected then we don’t hear any voice.
Also attached is the mail from vendor regarding their findings.
Call transfer issue in SIP to analogue convertor
Call transfer issue in SIP to analogue convertor
You do not have the required permissions to view the files attached to this post.
Re: Call transfer issue in SIP to analogue convertor
below is the mail from vendor (Zhone)
Dears
Please note that for starters, the Alcatel PBX is sending a "send only" INVITE to the zNID, and the zNID is responding back with a proper "receive only" 200 OK response.
The Alcatel PBX rejects all upstream RTP from the zNID (as expected) and the zNID stops sending upstream RTP (as expected), but the Alcatel PBX doesn't continue sending downstream RTP to the zNID.
The first issue here is the Alcatel PBX is telling the ONT that it will keep the RTP connection alive by continuing to send downstream RTP packets to the zNID, but it doesn't actually do so .
The second issue is that the Alcatel PBX never sends any SIP signaling packets to the zNID to re-establish an RTP connection with 179.
Look at the SIP Signaling flow diagram below.
In figure 2, 192.168.12.152 is the zNID, and 192.168.12.8 is the Alcatel PABX.
At timestamp 21.366 the switch sends a "sendonly" INVITE to the zNID
All RTP to the zNID stops.
The zNID never receives another SIP message
At 47 seconds, the zNID sends a BYE (presumably when the local user hangs the phone up)
So please check Alcatel and share them the capture with analysis so they will be able to fix the issue .
Attached the packet trace file "
Dears
Please note that for starters, the Alcatel PBX is sending a "send only" INVITE to the zNID, and the zNID is responding back with a proper "receive only" 200 OK response.
The Alcatel PBX rejects all upstream RTP from the zNID (as expected) and the zNID stops sending upstream RTP (as expected), but the Alcatel PBX doesn't continue sending downstream RTP to the zNID.
The first issue here is the Alcatel PBX is telling the ONT that it will keep the RTP connection alive by continuing to send downstream RTP packets to the zNID, but it doesn't actually do so .
The second issue is that the Alcatel PBX never sends any SIP signaling packets to the zNID to re-establish an RTP connection with 179.
Look at the SIP Signaling flow diagram below.
In figure 2, 192.168.12.152 is the zNID, and 192.168.12.8 is the Alcatel PABX.
At timestamp 21.366 the switch sends a "sendonly" INVITE to the zNID
All RTP to the zNID stops.
The zNID never receives another SIP message
At 47 seconds, the zNID sends a BYE (presumably when the local user hangs the phone up)
So please check Alcatel and share them the capture with analysis so they will be able to fix the issue .
Attached the packet trace file "
You do not have the required permissions to view the files attached to this post.
Re: Call transfer issue in SIP to analogue convertor
hi, something to check is if direct RTP is set true. if so try to set it as false and test.
I'm not OXO trained but have done this in the past and it fixed a lot of issues with 3rd party equipment.
others may have better options.
I'm not OXO trained but have done this in the past and it fixed a lot of issues with 3rd party equipment.
others may have better options.
Best Regards
Murray
ACSE 10.0 corporate
ACSE 6.x IPT data
Murray
ACSE 10.0 corporate
ACSE 6.x IPT data
Re: Call transfer issue in SIP to analogue convertor
401 ! related to authentification
rfc3261
Failure to authenticate - 401 or 407?
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.
Authentication for ACK and CANCEL
Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK.
UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK.
Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place).
rfc3261
Failure to authenticate - 401 or 407?
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.
Authentication for ACK and CANCEL
Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK.
UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK.
Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place).
