Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments

From: Brett Tate <[email-masked]>
Date: Fri, 12 Oct 2012 16:26:33 +0000

The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244bis-callflows-01 section 3.7.

1) All of the requests must include Max-Forwards to be RFC 3261 compliant.

2) Figure is missing an ACK for 302; consider it optional to also include the ACK message details.

3) For draft-ietf-sipcore-rfc4244bis compliance, F1 appears to need a History-Info.

4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs mp=1 added to the Contact.

5) F1 and F6 are missing SIP/2.0

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, or by sending an email to [email-masked], and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: <[email-masked]>
Date: Mon, 15 Oct 2012 16:50:44 +0200

Hi Brett,

> 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs mp=1 added to the

I understand RFC4244bis correct that the adding of mp=1 needs only to be done when it is a redirect server which carol's end device is not.

RFC4244bis
...
8.  Redirect Server Handling of History-Info Header Fields

   A redirect server MUST follow the procedures in Section 9.1 when it
   receives a SIP Request.  A redirect server MUST follow the procedures
   in Section 9.4 when it sends a SIP Response.  When generating the
   Contact header field in a 3xx response, the redirect server MUST add
   the appropriate "mp", "np" or "rc" header field parameter to each
   Contact header field as described in Section 10.4, if applicable.
...

Best Regards

Roland

---

From: Brett Tate <[email-masked]>
Date: Mon, 15 Oct 2012 15:30:33 +0000

Hi Roland,

Based upon the following RFC 3261 definition of Redirect Server, Bob's client is a redirect server.  Thus the parameter must be added.  And if not added by the Redirect Server, F4 is non compliant to the following draft-ietf-sipcore-rfc4244bis section 10.4 MUST NOT.

RFC 3261 section 6:

"Redirect Server: A redirect server is a user agent server that
 generates 3xx responses to requests it receives, directing the
 client to contact an alternate set of URIs."

Draft-ietf-sipcore-rfc4244bis-10 section 10.4:

"If the Contact header field
 does not contain an "rc" or "mp" header field parameter, then the SIP
 entity MUST NOT include an "rc" or "mp" header field parameter in the
 hi-target-param in the hi-entry when the request is retargeted to a
 contact URI received in a 3xx response."

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 15, 2012 10:51 AM
> To: Brett Tate; [email-masked]; draft-ietf-sipcore-rfc4244bis-
> [email-masked]
> Subject: AW: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01:
> section 3.7 comments
> 
> Hi Brett,
> > 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs
> mp=1 added to the
> > Contact.
> 
> 
> I understand RFC4244bis correct that the adding of mp=1 needs only to
> be done when it is a redirect server which carol's end device is not.
> 
> RFC4244bis
> ...

---

From: <[email-masked]>
Date: Mon, 15 Oct 2012 17:50:45 +0200

Hi Brett,
Thank you for the clarification.
So then the contact in 302 I think, has to contain the mp=1.1 . Due to the last entry of:

 History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                      index=1.1;rc=1
correct?

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Brett Tate
Gesendet: Montag, 15. Oktober 2012 17:31
An: Jesske, Roland; [email-masked]; [email-masked]
Betreff: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments

Hi Roland,

RFC 3261 section 6:

"Redirect Server: A redirect server is a user agent server that  generates 3xx responses to requests it receives, directing the  client to contact an alternate set of URIs."

"If the Contact header field
 does not contain an "rc" or "mp" header field parameter, then the SIP  entity MUST NOT include an "rc" or "mp" header field parameter in the  hi-target-param in the hi-entry when the request is retargeted to a  contact URI received in a 3xx response."

>    Contact header field as described in Section 10.4, if applicable.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brett Tate <[email-masked]>
Date: Mon, 15 Oct 2012 17:51:41 +0000

> History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\

Someone more familiar with draft-ietf-sipcore-rfc4244bis should respond.  I find sections 5 and 10.4 a little ambiguous concerning the topic; the rc involvement adds to my confusion (e.g. can an mp=non-mp-index?).  It looks like section 10.4 applies: "The mapping was done by the receiving entity on its own authority, in which case the mp-value is the parent index of the hi-entry's index".

Based upon rfc4244bis-callflows sections 3.1 and 3.4, it should be mp=1

Based upon rfc4244bis-callflows sections 3.6 and 3.7 F4 History-Info, it should be mp=1

Based upon sipcore-rfc4244bis section 5 example, it should be mp=1.1

<snip>

> > > 4) If I understand draft-ietf-sipcore-rfc4244bis 
> > > correctly, F3 needs mp=1 added to the Contact.

---

From: <[email-masked]>
Date: Tue, 16 Oct 2012 18:34:18 +0200

Hi,
I was looking on all call flows regarding that issue.

And I found something in RFC4244bis which states:

...
   Note that there are two scenarios by which the "mp" header field
   parameter can be derived.

   o  The mapping was done by the receiving entity on its own authority,
      in which case the mp-value is the parent index of the hi-entry's
      index.

   o  The mapping was done due to receiving a 3xx response, in which
      case the mp-value is an earlier sibling or descendant of an
      earlier sibling of the hi-entry's index, that of the downstream
      request which received the 3xx response.
...

Nevertheless my question is how the UE indicate the correct sibling?

So it looks that it must be mp=1

Best Regrads

Roland

> Von: Brett Tate [mailto:[email-masked]]
> Gesendet: Montag, 15. Oktober 2012 19:52
> An: Jesske, Roland; [email-masked];
> [email-masked]
> Betreff: RE: [sipcore]
> draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments
>
> > So then the contact in 302 I think, has to contain the
> mp=1.1 . Due to
> > the last entry of:
> >
> Someone more familiar with draft-ietf-sipcore-rfc4244bis
> should respond.  I find sections 5 and 10.4 a little
> ambiguous concerning the topic; the rc involvement adds to my
> confusion (e.g. can an mp=non-mp-index?).  It looks like
> section 10.4 applies: "The mapping was done by the receiving
> entity on its own authority, in which case the mp-value is
> the parent index of the hi-entry's index".
>