> Right but these talk about adding 'ob' to the contact header. The text I > am referring to (1st para in section 4.3) talks about including the > outbound option-tag in the supported header. I guess this goes in > conjunction with including the ob parameter in the contact header? If > that is the case I did not make the connection till just now.
Kevin, You *always* include Supported: outbound if you support outbound. This is just normal RFC 3261 option-tag behavior. This has no special relationship with the 'ob' parameter. thanks, -rohan > Kevin > > -----Original Message----- > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 20, 2008 4:10 PM > To: Kevin Johns > Cc: Sumanth Channabasappa; Francois Audet; [email protected]; Cullen > Jennings; Rohan Mahy > Subject: RE: [Sip] Outbound-12 comments > > Hi Kevin, > >> Ok, so I don't recall any of this being discussed in outbound. So I >> think some text is in order to explain why the UA includes this and >> what the edge proxy is expected to do as a result. > > Its already there. UA behavior from the 3rd paragraph of Section 4.3: > >>If the UAC is sending a dialog-forming request, and wants all >>subsequent requests in the dialog to arrive over the same flow, the UAC > adds an 'ob' >>parameter to its Contact header. Typically this is desirable, but it is > >>not necessary for example if the Contact is a [GRUU]. The flow used for > >>the request is typically the same flow the UA registered over, but it >>could be a new flow, for example the initial subscription dialog for >>the [configuration framework] needs to exist before registration. > > Edge proxy behavior is the same as that for any other dialog forming > request and is described in the last paragraph of Section 5.3. > > thanks, > -rohan > > >> Kevin >> >> -----Original Message----- >> From: Sumanth Channabasappa >> Sent: Thursday, March 20, 2008 3:42 PM >> To: Kevin Johns; 'Francois Audet'; '[email protected]' >> Cc: 'Cullen Jennings'; 'Rohan Mahy' >> Subject: RE: [Sip] Outbound-12 comments >> >> Kevin, >> >> That is my understanding. This would support bootstrapping >> configuration (prior to registration). >> >> - S >> >> -----Original Message----- >> From: Kevin Johns >> Sent: Thursday, March 20, 2008 3:34 PM >> To: Francois Audet; Sumanth Channabasappa; [email protected] >> Cc: Cullen Jennings; Rohan Mahy >> Subject: RE: [Sip] Outbound-12 comments >> >> So this would seem to imply that the presence of outbound in the >> support header indicates that a flow should be established and the >> Edge Proxy record route with a flow token in order for the resulting >> NOTIFY to be delivered in the absence of the UA having registered? >> >> -----Original Message----- >> From: Francois Audet [mailto:[EMAIL PROTECTED] >> Sent: Thursday, March 20, 2008 3:27 PM >> To: Sumanth Channabasappa; Kevin Johns; [email protected] >> Cc: Cullen Jennings; Rohan Mahy >> Subject: RE: [Sip] Outbound-12 comments >> >> Like the SUBSCRIBE in the example call flow section (the first one). >> >>> -----Original Message----- >>> From: Sumanth Channabasappa [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, March 20, 2008 14:25 >>> To: Kevin Johns; Audet, Francois (SC100:3055); [email protected] >>> Cc: Cullen Jennings; Rohan Mahy >>> Subject: RE: [Sip] Outbound-12 comments >>> >>> > Section 4.3, Sending Non-REGISTER Requests, 1st paragraph - >>> "UAs that >>> > support this specification SHOULD include the outbound >>> option tag in a >>> >>> > Supported header field in a non-Register REGISTER request." >>> What is a >>> > non-Register REGISTER request? >>> >>> >>I think this is a typo: it should say "non-Register request.". >>> >>> > Further why is this recommended? I did not see this >>> information being >>> > used by the edge proxy elsewhere in the document? >>> >>> >>That is a good question. Rohan? Cullen? >>> >>> [S] An example of a non-REGISTER request is a SIP SUBSCRIBE message. >>> I >> >>> am guessing this requirement refers to the use of outbound in such >>> cases. (We use the 'ob' parameter within the SIP Configuration >>> Framework.) >>> >>> >>> - S >>> >> > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
