|
One of the forwarding rules for our system is to
ring ALL phones in the system, which is done by forking the INVITE to all UAs. I
have a device that supports two analog phones, each with its own UA. When
the proxy forks the request, it sends two separate transactions (different
branch parameter values), one to each analog phone UA. The first
transaction is accepted and returns a 180 ringing, but the second returns a 400
bad request.
Since the two devices are sharing the same SIP
stack, the transactions are seen to be for the same dialog. Since the CSeq
number is not incremented for this dialog, in the second transaction, the
transaction is rejected.
->original request to proxy
INVITE sip:[EMAIL PROTECTED]:5060
SIP/2.0
From: JONES JENNIFER<sip:[EMAIL PROTECTED]:5060>;tag=c0a86501-13c4-404af6ab-3a1da04-6752 To: <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.101.1:5300;received=192.168.101.1;branch=z9hG4bK-404af6ab-3a1da04-2a23 Max-Forwards: 70 ->forked request to analog phone 1 UA
INVITE sip:[EMAIL PROTECTED]:5281
SIP/2.0
From: JONES JENNIFER<sip:[EMAIL PROTECTED]:5060>;tag=c0a86501-13c4-404af6ab-3a1da04-6752 To: <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.101.1:5060;branch=z9hG4bK-8138494148 Record-Route: <sip:192.168.101.1:5060> Via: SIP/2.0/UDP 192.168.101.1:5300;received=192.168.101.1;branch=z9hG4bK-404af6ab-3a1da04-2a23 Max-Forwards: 70 ->forked request to analog phone 2 UA
INVITE sip:[EMAIL PROTECTED]:5282 SIP/2.0 From: JONES JENNIFER<sip:[EMAIL PROTECTED]:5060>;tag=c0a86501-13c4-404af6ab-3a1da04-6752 To: <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.101.1:5060;branch=z9hG4bK-0441486704 Record-Route: <sip:192.168.101.1:5060> Via: SIP/2.0/UDP 192.168.101.1:5300;received=192.168.101.1;branch=z9hG4bK-404af6ab-3a1da04-2a23 Max-Forwards: 70 So I'm a little confused on how two requests within
the same device should be distinguished from one another. Should the proxy
be originating two new dialogs (different from tags?, different call
ids?)? If so how should the new dialogs be linked back to the dialog from
the originating device? Or is this an implementation issue in the SIP
stack? Is there something else it should be using to distinguish the two
dialogs?
thanks,
Steve Nelson
|
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
