Subject: [Sipping] Fwd: [Fwd: WGLC of draft-ietf-sipping-service-examples-10.txt]

From: "nagesh kumar" <[email-masked]>
Date: Thu, 22 Jun 2006 14:32:27 +0530

Hi,

Following are the review comments for sections 2.7, 2.8 and 2.9 (sections
assigned to me) of draft-ietf-sipping-service-examples-10.txt.

Regards
Nagesh

=====

2.7

F3 - Here proxy sends 181 when it is forwarding the call. However, proxy
shall not generate any response by itself as per RFC 3261 - P110.
"Since a proxy may not insert a tag into the To header field of a 1xx
response to a request that did not contain one, it cannot issue
non-100 provisional responses on its own. "

F4 - the t= line in the forwardede SDP shall be identical to what is
received. ( 0 is missing).

F13 - the 1st Via header bracnch parameter shall be identical to what is
sent in F12. (Currently, "1" is missing in the end for the latter.)

2.8

F6 - Here proxy sends 181 when it is forwarding the call. However, proxy
shall not generate any response by itself as per RFC 3261 - P110.
"Since a proxy may not insert a tag into the To header field of a 1xx
response to a request that did not contain one, it cannot issue
non-100 provisional responses on its own. "

2.9

F10 - Here proxy sends 181 when it is forwarding the call. However, proxy
shall not generate any response by itself as per RFC 3261 - P110.
"Since a proxy may not insert a tag into the To header field of a 1xx
response to a request that did not contain one, it cannot issue
non-100 provisional responses on its own. "

F7 - To tag in the CANCEL shall be the same as that of 180 Ringing in F5.

F15 - the via branch of this message shall match with the second Via
header's branch parameter in F14.

General

All the other message call-flows have Allow header included in INVITEs and
responses. This shall be repeated for sections 2.7, 2.8 and 2.9 too.

On 6/4/06, Gonzalo Camarillo <[email-masked] > wrote:
>
> Hi,
>
> all of you in the 'To' field of this email have volunteered to review
> the service examples draft. Thanks a lot for agreeing to perform this
> review.
>
> This is how we would like to divide the work: in the list below, I have
> assigned a few sections to each of the reviewers. When you are done with
> your review, send it in a reply-to-all to the email below, which was the
> WGLC for this draft on the SIPPING mailing list. We would like to have
> all the reviews ready by the end of the WGLC, on July 1st.
>
>
> < [email-masked]>
>      2.1.  Call Hold
>      2.2.  Consultation Hold
>
> <[email-masked] >
>      2.3.  Music On Hold
>      2.18. Automatic Redial
>      2.19. Click to Dial
>
> < [email-masked]>
>      2.4.  Transfer - Unattended
>      2.5.  Transfer - Attended
>      2.6.  Transfer - Instant Messaging
>
> < [email-masked]>
>      2.7.  Call Forwarding Unconditional
>      2.8.  Call Forwarding - Busy
>      2.9.  Call Forwarding - No Answer
>
> < [email-masked]>
>      2.10. 3-way Conference - Third Party is Added
>      2.11. 3-way Conference - Third Party Joins
>
> < [email-masked]>
>      2.12. Single Line Extension
>
> <[email-masked] >
>      2.13 . Find-Me
>
> <[email-masked]>
>      2.14. Call Management (Incoming Call Screening)
>      2.15. Call Management (Outgoing Call Screening)
>
> <[email-masked]>
>      2.16. Call Park
>      2.17. Call Pickup
>
>
> Thanks,
>
> Gonzalo
>
>
>
> -------- Original Message --------
> Subject: WGLC  of draft-ietf-sipping-service-examples-10.txt
> Date: Thu, 11 May 2006 20:37:40 +0300
> From: Gonzalo Camarillo < [email-masked]>
> To: sipping < [email-masked]>
> CC: Samuli Pöykkö <[email-masked]>,  Mary Barnes
> < [email-masked] >, Alan Johnston <[email-masked]>, Robert
> Sparks < [email-masked]>,  [email-masked]
>
> Folks,
>
> we would like to working group last call (WGLC) the following draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-10.txt
>
>
> as you have probably noticed if you clicked on the link above, this is a
> very long draft. Therefore, we would like to get at least ten volunteers
> to review it. We will assign a couple of sections to each reviewer.
>
> If you are interested and willing to review this draft, please send an
> email to the SIPPING chairs.
>
> The email below should be considered as a WGLC comment:
>
> http://www1.ietf.org/mail-archive/web/sipping/current/msg10886.html
>
> This is the output of the idnits tool:
>
> idnits 1.96
>
> tmp/draft-ietf-sipping-service-examples-10.txt:
>
>
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>
>     Checking conformance with RFC 3978/3979 boilerplate...
>
>     the boilerplate looks good.
>
>   * There is 1 instance of too long lines in the document, the longest one
>
>     being 1 character in excess of 72.
>
>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>     Nothing found here (but these checks do not cover all of
>     1id-guidelines.txt yet).
>
>   Miscellaneous warnings:
>   - Line 1028 has weird spacing: '... /* Bob  place...'
>   - Line 1404 has weird spacing: '... /* Bob  takes...'
>   - Line 1732 has weird spacing: '... /* Bob  place...'
>   - Line 2459 has weird spacing: '...and Bob  have ...'
>   - Line 2597 has weird spacing: '... /* Bob  puts ...'
>   - (4 more instances...)
>
>   Experimental warnings:
>   - Unused Reference: [18] is defined on line 7860, but not referenced
>   - Unused Reference: [13] is defined on line 7839, but not referenced
>   - Unused Reference: [14] is defined on line 7842, but not referenced
>   - Unused Reference: [1] is defined on line 7795, but not referenced
>
>
>
>
> This WGLC will end on July 1st, 2006 (a long draft needs a long WGLC).
>
> Thanks,
>
> Gonzalo
> SIPPING co-chair
>
>
>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 22 Jun 2006 11:14:57 -0400

From: "nagesh kumar" <[email-masked]>

I think the situation is more complex than that.  The entire paragraph
on page 110 is (RFC 3261 section 16.7 item 6):

         Since a proxy may not insert a tag into the To header field of
         a 1xx response to a request that did not contain one, it cannot
         issue non-100 provisional responses on its own.  However, it
         can branch the request to a UAS sharing the same element as the
         proxy.  This UAS can return its own provisional responses,
         entering into an early dialog with the initiator of the
         request.  The UAS does not have to be a discreet process from
         the proxy.  It could be a virtual UAS implemented in the same
         code space as the proxy.

Such a virtual UAS can return a provisional response, but it is under
the constraint that if it adds a to-tag, it has to create its own
to-tag, because it is creating a separate early dialog.  (And indeed,
it cannot predict the to-tag that the ultimate recipient will choose.)
This limits the usefulness of proxy-generated provisional responses,
as there is no way to correlate them with their sibling "real"
responses as against responses from other forks that were made closer
to the UAC.

But it appears that 8.2.6.2 requires that all provisional responses
other than 100 must have a to-tag:

   However, if the To header field in the request did not contain a
   tag, the URI in the To header field in the response MUST equal the
   URI in the To header field; additionally, the UAS MUST add a tag to
   the To header field in the response (with the exception of the 100
   (Trying) response, in which a tag MAY be present).

As a practical matter, it doesn't make a difference if a virtual UAC
creates a one-use to-tag vs. not creating one at all, as neither
carries any additional information.

Checking for examples, RFCs 2543, 3666, and 4542 have examples of
non-100 provisional responses, and all examples have to-tags.
Checking the Internet-Drafts I have archived, three show examples with
to-tags, and one shows an example without a to-tag.

So it seems a sound conclusion that both the specification and the
archived examples require a to-tag on non-100 provisional responses.
In that light, proxies are allowed to generate 1xx responses for
requests they handle, but all of the 181 responses in
draft-ietf-sipping-service-examples-10 need to have to-tags added.
E.g.:

      F3 (181 Call is Being Forwarded) Proxy -> Alice

      SIP/2.0 181 Call is Being Forwarded
      Via: SIP/2.0/TLS client.atlanta.example.com:5061
       ;branch=z9hG4bK74bf9
       ;received=192.0.2.103
      From: Alice <sips:[email-masked]>;tag=1234567
-     To: Bob <sips:[email-masked]>
+     To: Bob <sips:[email-masked]>;tag=bc2413ce
      Call-ID: [email-masked]
      CSeq: 1 INVITE
      Content-Length: 0

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 22 Jun 2006 19:57:59 +0200

Dale,

My interpretation was always that 181 could be sent without to-tag

If you add a to-tag, it becomes dialog-creating, and should also have a 
Contact header. Furthermore, the UAC would probably send a BYE on this 
dialog, and the proxy would have to make sure not to forward that BYE

Regards,

jeroen

----- Original Message ----- 
From: "Dale R. Worley" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 22, 2006 5:14 PM
Subject: Re: [Sipping] Fwd: [Fwd: WGLC 
ofdraft-ietf-sipping-service-examples-10.txt]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 22 Jun 2006 14:12:22 -0400

From: "Jeroen van Bemmel" <[email-masked]>

That seems sensible to me, but the normative documents seem to forbid
it.

True, I suppose that a Contact would be necessary.  But the 181 would
only create an early dialog, which would eventually time out.  The UAC
could send a BYE to dispose of it, and the proxy would be required to
virtually forward it to the virtual UAS, which would have to respond
200.  But the proxy can recognize such BYEs by their dialog
identifiers and contacts.

Perhaps we should amend RFC 3261 to allow call-progress responses
without to-tags?

Dale