headers
Jonathan Rosenberg | 1 Feb 2005 06:12
Picon
Favicon

Re: Provisional response to terminate early dialog


Robert Sparks wrote:

> How is this bound to 64T1?
> 
> It's an INVITE transaction - it can pend potentially indefinitely 
> (though timer C will likely kick in to muck up the works).

Oops, you are right. My brain is still not up to speed due to the nasty 
cold I suffered through this weekend.

> 
> I can see the kind of cases Christer is considering:
> 
>   1) You parallel fork to several places. All initiate early media. All 
> but one
>        return an error code that doesn't stimulate immediate forwarding 
> in the
>        proxy response context (say, 401just to see the situation, as odd 
> as that
>        would be to mix w/ early media). One leg just stays pending. The 
> initiating
>        UA will hold onto the resources for early media for _all_ of 
> those legs until
>        the pending leg completes.
> 
> 2) If you have a serial forking proxy, and each leg initiates early 
> media, at the
>     end of the fork, the initiating UA is holding early media resources 
> for each
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 1 Feb 2005 07:22
Picon
Favicon

Re: Abbreviated WGLC for draft-ietf-sip-refer-with-norefersub-00.txt

comments:

1. the title should indicate that this draft has something to do with SIP.

2. Abstract is too short. It will be bounced by rfc-ed in this form. You 
need to provide a little more context here.

Propose:

The REFER method has been defined for the Session Initiation Protocol 
(SIP) for the purposes of asking a user agent to generate a request to a 
specified Uniform Resource Identifier (URI). Sending a REFER request 
creates an implicit subscription that allows the referor to get updates 
on the status of the request generated by the REFER. However, experience 
has shown that in many cases this implicit subscription is not 
desirable. This specification defines a new SIP option tag value that 
causes the recipient of the REFER to suppress the implicit subscription.

3. The introduction seems stranded without the motivation. I would 
rename "Motivation" to "introduction" and copy the only paragraph in the 
introduction to the end of the motivation section.

> REFER-Recipient to the REFER-Issuer.  The REFER-Recipient may choose
>     to cancel the implicit subscription with this NOTIFY.  

by setting the Subscription-State header field value in the NOTIFY to 
"terminated".

> The "norefersub" option tag MUST be used by the REFER-Issuer only
>     when the REFER-Issuer can be certain that the REFER request will not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Rosenberg | 1 Feb 2005 07:27
Picon
Favicon

Re: Minor anomaly in RFC 3261 Registration example?

And in particular, this bug is in bugzilla already:
http://bugs.sipit.net/show_bug.cgi?id=682

-Jonathan R.

Robert Sparks wrote:

> The bugzilla database is available at bugs.sipit.net.
> 
> RjS
> 
> On Jan 14, 2005, at 4:06 PM, Jain, Rajnish wrote:
> 
>> Folks:
>>
>> Not sure if this minor anomaly has been reported before and is already 
>> logged in SIP bugzilla (which seems to be down right now). Apologies 
>> if this is a repetition.
>>
>>
>>
>> Section 10.3 of RFC 3261 states the following:
>>
>>       8. The registrar returns a 200 (OK) response.  The response MUST
>>           contain Contact header field values enumerating all current
>>           bindings.  Each Contact value MUST feature an "expires"
>>           parameter indicating its expiration interval chosen by the
>>           registrar.  The response SHOULD include a Date header field.
>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christer Holmberg (JO/LMF | 1 Feb 2005 08:07
Picon
Favicon

RE: Provisional response to terminate early dialog


Hi,

In my use-case I actually meant to say SERIAL forking, not parallel. Of course, from a UAC perspective it
doesn't matter (it doesn't know how the forking is done).

However, the fact that we can receive early media from multiple UASs in the parallel case I probably
something we can do very little about, and if many nodes send early media at the same time it may not help much
to have an indication on when a dialog is terminated.

In the serial case, however, there will only be early media from one node at a time. But, when one fork is
terminated, the media may "switch" to another dialog, initiated by the next fork. But, again, since the
UAC doesn't knows that there will be no more early media from the first fork it may keep the resources
reserved for the first fork until it receives a final response from another fork.

Jonathan said in his second reply that we need to find out if this will be a problem in reality.

The reason for my initial question was basically due to the work on supplementary services which is
currently ongoing in the ETSI TISPAN and 3GPP bodies. Some services will provide early
media/announcments, and one idea is that they will be associated to a specific early dialog. The media
coming from the actual UAS will then be associated with another dialog. To describe it easy, from a SIP
perspective there would be a proxy doing serial forking, first to the announcement UAS, and then to the
actual UAS.

The problem is that a 3GPP UAC may choose not to accept (for a number of technical reasons) multiple early
dialogs, so in this case it would probably accept the first "announcement" dialog, but not the UAC-UAS
dialog - which is of course bad. However, if the node doing the forking would be able to directly, when the
announcement has finished, indicate to the UAC that the announcement dialog is terminated, the UAC could
free the resources associated with that and then accept the UAC-UAS dialog.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simone Leggio | 1 Feb 2005 09:45
Picon
Picon
Favicon

Questions on the SIP identity draft

Hi all,

I have a couple of questions about the SIP identity draft, i.e.

Enhancements for Authenticated Identity Management
in the Session Initiation Protocol (SIP)

draft-ietf-sip-identity-03

1) In the background section, I quote:
>  Note that the scope of this
>    document is limited to providing this identity assurance for SIP
>    requests; solving this problem for SIP responses is more complicated,
>    and is a subject for future work.

Why can't SIP Identity be applied to responses as well? Why can't an 
Identity header field be added based on the relevant response fields? At 
least, final responses like 200 OK.
For more security, instead of adding only the addr-spec component of the 
To header field, it may be added also the tag part. Am I forgetting some 
relevant security issue?

2) Section 10 says that

> The REGISTER method uses Contact header fields in very unusual ways that
>    complicate its applicability to this mechanism.  Accordingly, the
>    Identity and Identity-Info header MUST NOT appear in REGISTER

Why can't the REGISTER be protected? Usually authentication happens 
because user agent and server share a common secret, i.e. password. What
(Continue reading)

Permalink | Reply | 0 comments |
headers
Suganya | 2 Feb 2005 01:04

sip and dns

Hi,

I have the following doubts and need some help.

a) In order to contruct DNS query, I googled-up and found RFCs 1034 and
1035. But it doesn't talk of SIP. Can those guidelines be used for
constructing the DNS for SIP related queries?

b) Where to send the DNS query from UAC?

c) Unlike RFC 3261 which clearly tells how to construct invite, ack, etc...
messages, RFC 3263 specifies no syntax or query format to construct the DNS
query.

Regards,
B.Suganya

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 1 comment |
headers
Shekar, Nagesh Soma (Shekar)** CTR ** | 1 Feb 2005 20:20
Picon
Favicon

Requests within SIP Dialog and Contact Header

The Contact header is defined as a Mandatory Header in some of Request messages,
like NOTIFY as a mandatory header.
 
I am trying to understand if this is required for SIP header like Contact to be mandatory
in SIP requests that are sent in a dialog that is already setup with a INVITE transaction.
If it is required, then what is the intent of making it Mandatory and how it should be used.
 
In my opinion, I think a distinction needs to be made between the case how a request
such as NOTIFY is used. If it is used to setup a dialog, then SIP headers like Contact
should be mandatory, otherwise they should be not even be present.
 
Nagesh Shekar
Email: shek <at> lucent.com

 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 1 comment |
headers
Elwell, John | 1 Feb 2005 21:50
Picon

RE: Abbreviated WGLC for draft-ietf-sip-refer-with-norefers ub-00.txt

Robert,

Section 3, 2nd paragraph: "One purpose of requiring the implicit
subscription and initial NOTIFY is to allow for the situation where the
REFER request gets forked and the REFER-Issuer needs a way to see the
multiple dialogs that may be established as a result of the forked REFER."
Surely the REFER-Issuer will see the multiple dialogs as a result of
receiving multiple 2xx responses to the REFER request?

Consequently, concerning the following statement in section 4: "The
"norefersub" option tag MUST be used by the REFER-Issuer only when the
REFER-Issuer can be certain that the REFER request will not be forked." - is
it really necessary for MUST strength?

Then at the end of section 4: "If the REFER-Recipient is willing to grant
the "norefersub" behavior for the issued REFER request, it MUST insert a
Supported: norefersub header in the 2xx response to the REFER-Issuer.  In
this case no dialog is created."
Surely a dialog is created by the 2xx response to REFER?

John

> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On 
> Behalf Of Robert Sparks
> Sent: 31 January 2005 17:34
> To: Robert Sparks
> Cc: SIP WG; Rohan Mahy; Orit Levin; Dean Willis
> Subject: Re: [Sip] Abbreviated WGLC for 
> draft-ietf-sip-refer-with-norefersub-00.txt
> 
> The LC the chairs initiated ends today.
> 
> Please read this draft and comment. It's very short - please do this  
> now.
> 
> We've talked about this idea a lot - let make sure the talk 
> is captured  
> in the draft.
> 
> RjS
> 
> On Jan 26, 2005, at 4:22 PM, Robert Sparks wrote:
> 
> > Initial LC Comments:
> >
> > First paragraph of Section 3 calls out 481ing an initial 
> NOTIFY. The  
> > -dialog-usage-
> > draft shows that is a bad idea, especially for in-dialog REFERs.  
> > Suggest trimming
> > the sentence to end after (Expires 0).
> >
> > Section 4 fourth paragraph: It would help implementers to call out  
> > explicitly that the
> > 200 response to the REFER will not contain a Supported or Require  
> > header containing
> > the norefersub token.
> >
> > Section 4 fifth paragraph: This needs more definition. How is it  
> > rejected? 603, 420, or
> > something else? Implementors will need some guidance here 
> on when to  
> > use which
> > error response. I think (but am not dead certain at the 
> moment) that  
> > 420 is almost always
> > what you want to use.
> >
> > Section 4 sixth paragraph: Is Supported: in the response 
> really the  
> > right thing? Eventlist
> > uses Require: in the response to a SUBSCRIBE. The intent of the  
> > normative behavior in
> > this paragraph is to let a Refer-issuer who only included 
> Supported:  
> > know whether or
> > not a subscription was actually created. Require: (I'm using this  
> > extension) in the response
> > fits that better than Supported: (I could use this 
> extension if you  
> > want to).
> >
> > Section 4 sixth paragraph: Suggest replacing "In this case, 
> no dialog  
> > is created" with
> > "In this case, no implicit subscription is created. As a 
> consequence,  
> > no new dialog
> > is created if this REFER was issued outside any existing dialog."
> >
> > Section 5: Probably worth also calling out using 
> Max-Forwards: 0 to  
> > prevent forking
> > for those (rare now, but hopefully not rare forever) cases where  
> > signaling can get to
> > the refer target without going through a proxy.
> >
> > Section 6: Must replace "tradewind" with "example" throughout.
> >
> > Section 8: "threads" should be "threats", It would be good 
> to pull any  
> > discussion
> > that led to this conclusion together for when the IESG asks if we  
> > _really_ thought
> > about this. Have we talked about what would happen if a SIP  
> > intermediary (or an
> > unauthorized MitM) just injected a Require: norefersub into 
> a REFER  
> > request?
> >
> > RjS
> >
> >
> > On Jan 24, 2005, at 5:07 PM, Rohan Mahy wrote:
> >
> >> Hi Folks,
> >>
> >> I'd like to begin an abbreviated WGLC for:
> >>
> >> 	http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- 
> >> norefersub-00.txt
> >>
> >> Since this document is extremely short and has been discussed  
> >> extensively, WGLC will end on February 1st.
> >>
> >> thanks,
> >> -rohan
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> >> Use sipping <at> ietf.org for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors <at> cs.columbia.edu for questions on current sip
> > Use sipping <at> ietf.org for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 2 comments |
headers
Gonzalo Camarillo | 1 Feb 2005 21:51
Picon
Favicon

Re: Draft defining the Accept-Disposition header field

Hi Cullen,

inline:

Cullen Jennings wrote:

>>>I'm not really sure what the problem is that this solves.
>>
>>it lets a UA know whether the remote UA supports a particular
>>disposition type. Right now, UAs guess this information based on the
>>support for MIME types. For example, if the remote UA supports
>>application/sdp, my UA assumes that the remote UA supports the 'session'
>>disposition type... but what about 'early-session'?
>> 
> 
> Seems like Supported header is a better way to solve this particular issue

Yes, we can define new option tags for everything we want to 
negotiate... but defining an option tag that just means "I support this 
disposition type" seems like duplicating stuff unnecessary (e.g., 
defining an option tag that means that the UA supports the early-session 
disposition type).

In addition, we have an error response (415) that, per its definition, 
should be returned if the UAS does not support a MIME type or a 
disposition type in the request... we have a means to express which MIME 
types the UAS supports if the problem was an unknown MIME type, but we 
do not have anything to express which disposition types the UAS 
supports, in case the problem had to do with a disposition type. This 
information can come handy for debugging.

> I guess I am wondering if using the MIME dispositions is really the right
> way to basically tell the UA what you want it to do with a given SIP command
> - what does recipient-list mean in the context of email or other users of
> MIME?

Yes, it has already been pointed out that disposition types are context 
dependent. The issue is that, in email, any disposition type belongs to 
the same context: the reception of an email message. In SIP, we have 
different contexts. For example, the reception of a body whose 
disposition type is 'session' in an INVITE request makes sense, but what 
happens if it is received in a MESSAGE?

Gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 1 Feb 2005 21:53
Picon
Favicon

Re: Draft defining the Accept-Disposition header field

Hi Cullen,

inline:

Cullen Jennings wrote:

>>>I'm not really sure what the problem is that this solves.
>>
>>it lets a UA know whether the remote UA supports a particular
>>disposition type. Right now, UAs guess this information based on the
>>support for MIME types. For example, if the remote UA supports
>>application/sdp, my UA assumes that the remote UA supports the 'session'
>>disposition type... but what about 'early-session'?
>> 
> 
> Seems like Supported header is a better way to solve this particular issue

Yes, we can define new option tags for everything we want to 
negotiate... but defining an option tag that just means "I support this 
disposition type" seems like duplicating stuff unnecessary (e.g., 
defining an option tag that means that the UA supports the early-session 
disposition type).

In addition, we have an error response (415) that, per its definition, 
should be returned if the UAS does not support a MIME type or a 
disposition type in the request... we have a means to express which MIME 
types the UAS supports if the problem was an unknown MIME type, but we 
do not have anything to express which disposition types the UAS 
supports, in case the problem had to do with a disposition type. This 
information can come handy for debugging.

> I guess I am wondering if using the MIME dispositions is really the right
> way to basically tell the UA what you want it to do with a given SIP command
> - what does recipient-list mean in the context of email or other users of
> MIME?

Yes, it has already been pointed out that disposition types are context 
dependent. The issue is that, in email, any disposition type belongs to 
the same context: the reception of an email message. In SIP, we have 
different contexts. For example, the reception of a body whose 
disposition type is 'session' in an INVITE request makes sense, but what 
happens if it is received in a MESSAGE?

In any event, as Paul suggested, I believe it is good to analyze all the 
issues related to SIP and MIME stuff and make decisions in one way or 
another. At this point, there are issues that haven't got enough attention.

Gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |

Gmane