Subject: [Sip] Simultaneous client Non-Invite Transactions

From: "Eric Tremblay" <[email-masked]>
Date: Wed, 12 Apr 2006 20:24:11 -0400

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-masked]>
Technical Product Manager
M5T Centre D'Excellence en Telecom, Inc.
http://www.m5t.com
tel: +1-819-829-3972 x238

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Eric Tremblay" <[email-masked]>
Date: Wed, 12 Apr 2006 20:30:46 -0400

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-masked]] 
	Sent: April 12, 2006 20:24
	To: [email-masked]
	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?

	- 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?

	Regards, 

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