OXE-LYNC SIP trk "491 Proxy side reinvite failed, pass..

Post Reply
User avatar
arad
Member
Posts: 7
Joined: 06 Jan 2010 06:27

OXE-LYNC SIP trk "491 Proxy side reinvite failed, pass..

Post by arad »

hello guys.
i need help with the following issue in a OXE R10.1 netw -connected to MS LYNC 2010 via SIP trk.
i have two nodes in a ABC-F network. N1 also has a ISDN trk with the operator and a SIP trk with MS LYNC 2010.
A.Outgoing Calls from Lync to every direction go OK.
A1.Calls from N1==>(SIP)==>LYNC(both MOC&conf room) go OK.
B.Incoming calls from Operator==>(ISDN)==>N1==>(SIP)==>LYNC go OK.
C.Incoming calls from N2-->(ABC-F)-->N1-->(SIP)-->LYNC(conf room) go OK.
D.Incoming calls from N2-->(ABC-F)-->N1-->(SIP)-->LYNC(MOC) FAIL!!(32s timer).

From what i've learned from the traces, in the case w/ transit (C & D) from ABC link there's a second INVITE in SIP signaling from .
In the case when Lync conf room is called, both INVITE msgs get 200 OK (call OK). When the MOC is called, the first INVITE is responded w/ 200 OK,
but the second INVITE receives "SIP 391 Status: 100 Trying" and then "SIP 573 Status: 491 Proxy side reinvite failed, pass result to GW.".
So, as the 200 OK never comes from the LYNC side, after the 32s timer expires the call is dropped. Also, in spite of first 200 OK + ACK,
the SDP session is not negociated, because in wireshark trace i can see that Alcatel Side is sending G711 PCMA and MS LYNC is sending G711 PCMU.
Any suggestions are welcomed!
thank you,
You do not have the required permissions to view the files attached to this post.
User avatar
alex
Senior Member
Posts: 1498
Joined: 06 Jul 2004 07:27
Contact:

Re: OXE-LYNC SIP trk "491 Proxy side reinvite failed, pass..

Post by alex »

arad wrote:... the 200 OK never comes from the LYNC side...
the SDP session is not negociated...
RE-INVITE is not accepted on the Lync side. 99% problem with the media on the Lync side. Check Lync configuration.
But the best way is to compare traces of C and D cases so I hope it would be clear what's not accepted by the Lync.

PS Why they MS use such a strange SIP 491 "Request pending" response description? What in hell is " Proxy side reinvite failed"?
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
User avatar
arad
Member
Posts: 7
Joined: 06 Jan 2010 06:27

Re: OXE-LYNC SIP trk "491 Proxy side reinvite failed, pass..

Post by arad »

Thank you very much for your answer.
Actually, what bothers me is why the calls to the ConferenceRoom go OK, while the calls to the Lync Client get this "SIP/2.0 491 Proxy side reinvite failed, pass result to GW".
Another Thing I don't understand is Why the calls transiting N1 are treated different than the calls originating in N1, as when they arive at the Mediation Server of MS LYNC. In the first case there are 2 INVITE msgs while in the first case there's only one INVITE.
Regarding what Alex is saying that the SDP is not beeing negociated, Another thing that i've learned is that in tha case w/ the call to the conf room(succeded), Alcatel sends PCMA rtp packets and MS LYNC sends PCMU RTPs. After the second exchange of (INVITE +200OK +ACK ) both sides exchange PCMA(calling party's codec).
In the case of the unsucceded call to the MOC Client, untill the 32s timer ends the call, each party is using its own codec (ALCATEL -PCMA, MS LYNC PCMU).
Attached is the trace for the call to the Conf Room (which succeds) .
You do not have the required permissions to view the files attached to this post.
User avatar
alex
Senior Member
Posts: 1498
Joined: 06 Jul 2004 07:27
Contact:

Re: OXE-LYNC SIP trk "491 Proxy side reinvite failed, pass..

Post by alex »

Check MS side configuration.
First of all compare the configuration of 6519 and 6581 extensions.
In both cases RE-INVITEs sent from OXE are identical but Lync reaction is different.
Looks like OXE switches to RTP but 6581 is not able to support it.
In a bad case (text.txt) Lync replies to INVITE with 183 Session Progress, 180 Ringing, 180 Ringing,183 Session Progress,183 Session Progress and then 200 OK. Though it is not a problem as they are mainly provisional messages but in general this behaviour is quite strange.
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Post Reply

Return to “SIP”