Oops, sorry, I realize this should have been posted to sip-implementors.
 
Moving to the proper list, and please make sure to reply only to
sip-implementors.
 
Regards,
 
EricT
 


________________________________

        From: Eric Tremblay [mailto:[EMAIL PROTECTED] 
        Sent: April 12, 2006 20:24
        To: [email protected]
        Subject: [Sip] Simultaneous client Non-Invite Transactions
        
        

        Hi All, 

        I have been digging the following question for a while without
any clear answers, so I think it may be worth a clarification in RFC
3261.

        Is it allowed to send a non-INVITE request on an existing dialog
while there is already a client non-INVITE request in progress on this
dialog?

        Here is a summary of my findings: 

        - In SIPWG Bugzilla, bug 113: The authors clearly wanted to
allow simultaneous non-INVITE transactions. 
        - In 3261, section 12.2.1.1 discusses how a UAC generates a
request within a dialog. This section does not disallow a UAC from
creating multiple non-INVITE client transactions.

        - In 3261, section 12.2.2 discusses how a UAS generates a
response to a request within a dialog. This section explicitly states
that a 500 response must be sent if the incoming request is
out-of-order.

        - In 3261, section 28, changes from RFC 2543, clearly states
that we can have multiple non-INVITE transactions on a dialog:

        -- quote 
           o  RFC 2543 was silent on whether a UA could initiate a new 
              transaction to a peer while another was in progress.  That
is now 
              specified here.  It is allowed for non-INVITE requests,
disallowed 
              for INVITE. 
        --- endquote 

        So on the UAC side, we allow it, and on the UAS side, we allow
it if the network behaves correctly, that is it does not reorder the
incoming requests.

        The problem I have is with a subscriber receiving multiple
NOTIFY over UDP, and as you might have guessed, the network reorders the
packets and then it sends a 500 to a NOTIFY, as per 3261, which removes
the subscription at the notifier. Is this the normal and expected
behavior?

        Thank you for any pointers you can provide, 

        Regards, 

        EricT 
        ________________________________________ 
        Eric Tremblay <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > 
        Technical Product Manager 
        M5T Centre D'Excellence en Telecom, Inc. 
        http://www.m5t.com <http://www.m5t.com>  
        tel: +1-819-829-3972 x238 

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to