| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
This segment from the UAS log might explain the
problem: BYE sip:149.49.54.131:5060 SIP/2.0 Via: SIP/2.0/UDP 149.49.54.139:5060;branch=z9hG4bK-d8754z-140bb16e606e763c-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:user@xxxxxxxxxxxxx:5060> To: <sip:osp@xxxxxxxxxxxxx:5060>;tag=e621417c From: <sip:c@xxxxxxxxxxxxx:5060>;tag=802e323d;OSP_PRIVATE Call-ID: MTc2MDM5MmI4YWYxOWQ3OWRmZDk2NDYzMDVmYjVmZWI. CSeq: 2 BYE Content-Length: 0 DEBUG | 20100818-171113.781 | OSP | RESIP:TRANSPORT
| 4116 | Transport.cxx:213 | Adding message to tx buffer to: [ V4 149.49.54.131:5060
UDP target domain=149.49.54.131 mFlowKey=0 ] DEBUG | 20100818-171113.828 | OSP | RESIP:TRANSPORT
| 4116 | Transport.cxx:287 | incoming from: [ V4 149.49.54.131:5060 UDP target
domain=unspecified mFlowKey=28440 ] STACK | 20100818-171113.828 | OSP | RESIP:TRANSPORT
| 4116 | Transport.cxx:288 | SIP/2.0 200 OK Via: SIP/2.0/UDP 149.49.54.139:5060;branch=z9hG4bK-d8754z-140bb16e606e763c-1---d8754z-;rport=5060 Contact: <sip:149.49.54.131:5060> To: <sip:osp@xxxxxxxxxxxxx:5060>;tag=2e5b9773 From: <sip:d@xxxxxxxxxxxxx:5060>;tag=b016b470;OSP_PRIVATE Call-ID: NjlhNDJlMWI3Zjk1YmY1YWMyMGY4NDgzYWFhZjFkZGE. CSeq: 2 BYE Content-Length: 0 The BYE is sent with Call-ID: MTc2MDM5MmI4YWYxOWQ3OWRmZDk2NDYzMDVmYjVmZWI
and the OK to this BYE is sent with Call-ID: NjlhNDJlMWI3Zjk1YmY1YWMyMGY4NDgzYWFhZjFkZGE. This means that the OK to the second BYE is sent
with the Call-ID of the dialog to which the first BYE belongs. As far as I understood from RESIPROCATE code, the
BYE transaction is recognized by the branch parameter and isn't dependant on
other fields, such as Call-ID. The problem is that the branch parameter in this
BYE is identical to the branch parameter in the BYE of the first dialog. This is the BYE of the first dialog, taken from
the log of the UAS (the side that sends the BYE): BYE sip:149.49.54.131:5060 SIP/2.0 Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-140bb16e606e763c-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:user@xxxxxxxxxxxxx:5060> To: <sip:osp@xxxxxxxxxxxxx:5060>;tag=e621417c From: <sip:c@xxxxxxxxxxxxx:5060>;tag=802e323d;OSP_PRIVATE Call-ID: MTc2MDM5MmI4YWYxOWQ3OWRmZDk2NDYzMDVmYjVmZWI. CSeq: 2 BYE Content-Length: 0 The question is: Why is the branch of the first BYE
is identical to the branch of the second BYE? Thanks From: Adam Roach [mailto:adam@xxxxxxxxxxx] As far as I know, this isn't a known issue. Although I won't have time
to look into the problem anytime soon, anyone who might be able to help you
would probably need debug logs from both user agents. Hi, I'm using RESIPROCATE in order to send INVITE to another
computer where I'm also using RESIPROCATE to accept the INVITE. After a few seconds the accepting side is sending BYE to the
side that sent the INVITE (the UAS sends BYE to the UAC). There are two such dialogs between the 2 sides: I send the
INVITE twice and receive the BYE twice, like this: UAC -> UAS: INVITE Call-Id: X UAC -> UAS: INVITE Call-Id: Y … … UAS -> UAC: BYE Call-Id: X UAS -> UAC: BYE Call-Id: Y However, sometimes the second BYE is not received by
RESIPROCATE, although I see it in wireshark. Is there some known issue about RESIPROCATE missing or
ignoring SIP messages? Thanks _______________________________________________resiprocate-users mailing listresiprocate-users@xxxxxxxxxxxxxxxList Archive: http://list.resiprocate.org/archive/resiprocate-users/
No virus found in this incoming message. |