From sip-bounces@ietf.org Tue Jan 01 20:26:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9sN0-0005I6-54; Tue, 01 Jan 2008 20:26:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J511V-00030i-U5 for sip-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J511V-0002yM-JB for sip@ietf.org; Wed, 19 Dec 2007 10:39:53 -0500 Received: from web92207.mail.cnh.yahoo.com ([203.209.250.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J511U-0000By-9j for sip@ietf.org; Wed, 19 Dec 2007 10:39:53 -0500 Received: (qmail 869 invoked by uid 60001); 19 Dec 2007 15:39:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.cn; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rQIgQr07AJDFcPMAuu0rDl1Y0BP5kwHNpBKdndB5EFqNvvcVcsmM1JEvd7GulLl4pC2CL8RAW3jW3Dp0Ud6KOZUPyfVM3ni65Z2vZbeQ/SVvi82p743IgZP99/ac7vfnbPsrVFhpLRuIS2svMMIBJLwyxraaZHudL1o9syE06YI=; X-YMail-OSG: 2kuWjnsVM1kD6zomo5qaPbynY00Sax.0CvShIxWYOMuDqwIRwpspgXreVEv2..MSIochFoIdaMhFDJYi.csdoJ72su3XUaVk9h0k Received: from [218.22.22.182] by web92207.mail.cnh.yahoo.com via HTTP; Wed, 19 Dec 2007 23:39:50 CST Date: Wed, 19 Dec 2007 23:39:50 +0800 (CST) From: =?gb2312?q?=C2=ED=E6=F7=20=20?= To: sip@ietf.org MIME-Version: 1.0 Message-ID: <723963.268.qm@web92207.mail.cnh.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 01 Jan 2008 20:26:08 -0500 Subject: [Sip] Some question about draft:A Framework for Session Initiation Protocol (SIP) Session Policies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0519298551==" Errors-To: sip-bounces@ietf.org --===============0519298551== Content-Type: multipart/alternative; boundary="0-478554592-1198078790=:268" Content-Transfer-Encoding: 8bit --0-478554592-1198078790=:268 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit I have some questions about the frame work proposed in the draft which defines a framework for SIP policy. See bellow: 1. What the advantage is in the proposed framework in which UA require its policy (which means it contacts policy server after contacts proxy) by itself? An alternative is, the proxy contacts the proxy server on behalf of the UA, and return or not return determined policies, which means UA need not involved in the procedure of contacting policy server. So why the one proposed in the draft is better? 2. If it retrieves policies according to call flow this draft, how a proxy knows that the policies in the resending request for the UA is genuine, especially for the specific ongoing request?(which means there should be security mechanism to avoid replay attacks).Can anyone give me some ideas or solutions? Thanks. _______ mjhorse --------------------------------- ÑÅ»¢ÓÊÏä´«µÝÐÂÄê×£¸££¬¸öÐԺؿ¨ËÍÇ×Åó£¡ --0-478554592-1198078790=:268 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
    I have some questions about the frame work proposed in the draft which defines a framework for SIP policy. See bellow:
    1. What the advantage is in the proposed framework in which UA require its policy (which means it contacts policy server after contacts proxy) by itself? An alternative is, the proxy contacts the proxy server on behalf of the UA, and return or not return determined policies, which means UA need not involved in the procedure of contacting policy server. So why the one proposed in the draft is better?
 
    2. If it retrieves policies according to call flow this draft, how a proxy knows that the policies in the resending request for the UA is genuine, especially for the specific ongoing request?(which means there should be security mechanism to avoid replay attacks).Can anyone give me some ideas or solutions?
 
Thanks.
_______
mjhorse

ÑÅ»¢ÓÊÏä´«µÝÐÂÄê×£¸££¬¸öÐԺؿ¨ËÍÇ×Åó£¡ --0-478554592-1198078790=:268-- --===============0519298551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0519298551==-- From sip-bounces@ietf.org Tue Jan 01 20:27:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9sO4-0005vo-8V; Tue, 01 Jan 2008 20:27:16 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5s3q-0002fd-7B for sip-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 19:17:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5s3p-0002bb-Np for sip@ietf.org; Fri, 21 Dec 2007 19:17:49 -0500 Received: from smtp-out.google.com ([216.239.33.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5s3m-0007re-EW for sip@ietf.org; Fri, 21 Dec 2007 19:17:49 -0500 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id lBM0Hghk008057 for ; Sat, 22 Dec 2007 00:17:43 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=hxaf7Jnad5pemOcPdtusw47Pg780mDKmp0cohxqLJ+BJFQ/zhPB1i3ajQW3koeznL o+uFagZTVr9u/VxOcjg1A== Received: from hs-out-2122.google.com (hsc55.prod.google.com [10.44.3.55]) by zps78.corp.google.com with ESMTP id lBM0HfXI007312 for ; Fri, 21 Dec 2007 16:17:41 -0800 Received: by hs-out-2122.google.com with SMTP id 55so444780hsc.10 for ; Fri, 21 Dec 2007 16:17:36 -0800 (PST) Received: by 10.150.143.14 with SMTP id q14mr688222ybd.113.1198282656246; Fri, 21 Dec 2007 16:17:36 -0800 (PST) Received: by 10.70.30.5 with HTTP; Fri, 21 Dec 2007 16:17:36 -0800 (PST) Message-ID: <6e608abf0712211617s40a6f974k5d15256100b02130@mail.gmail.com> Date: Sat, 22 Dec 2007 00:17:36 +0000 From: "Dave Burke" To: "Paul Kyzivat" In-Reply-To: <4766DCC6.3030708@cisco.com> MIME-Version: 1.0 References: <3A12F8FF-8623-484C-ABD4-DE00FBD03B87@softarmor.com> <4766DCC6.3030708@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 X-Mailman-Approved-At: Tue, 01 Jan 2008 20:27:15 -0500 Cc: sip-chairs@tools.ietf.org, SIP IETF , Dean Willis , mediactrl@ietf.org, Mark Scott Subject: [Sip] Re: Requested Expert Review Request: draft-ietf-mediactrl-vxml-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0472891568==" Errors-To: sip-bounces@ietf.org --===============0472891568== Content-Type: multipart/alternative; boundary="----=_Part_449_18274007.1198282656223" ------=_Part_449_18274007.1198282656223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Paul, Thanks a lot for the review. Mark and I have discussed each of these and I've responded to the comments below. Cheers, Dave [snip] Section 2.1: > > The ABNF of the URI seems excessively rigid in the ordering of > parameters - first the init-parameters, then the vxml-parameters, then > then any other uri-parameters. It also doesn't note that > 'uri-parameters' is defined in 3261. > DB> Good observation - ordering of the parameters was never intended. Your proposal looks good. However, while looking over this again, we found another issue which crept in late in the process related to the addition of JSON support. Specifically, the problem is that it is impossible to differentiate where vxml-params end and uri-parameters begin and hence which parameter values to interpret as JSON values and which as plain strings. We propose a change to limit JSON values to just the named VoiceXML session variables 'ccxml' and 'aai' (these were the two variables for which JSON support was originally sought). dialog-parameters = *(";" dialog-parameter) dialog-parameter = init-param / url-parameter ; defined in [RFC 3261] init-param = ";" (dialog-param / maxage-param / maxstale-param / method-param / postbody-param / ccxml-param / aai-param) dialog-param = "voicexml=" vxml-url ; vxml-url follows the URI ; syntax defined in [RFC3986] maxage-param = "maxage=" 1*DIGIT maxstale-param = "maxstale=" 1*DIGIT method-param = "method=" ("get" / "post") postbody-param = "postbody=" token ccxml-param = "ccxml=" json-value aai-param = "aai=" json-value json-value = false / null / true / object / array / number / string ; see RFC4627 > > > I'm confused about postbody: > > [snip] > > The interaction between these two escaping rules seems potentially > confusing. I *think* when this is all put together it means that the > body must first be encoded according to the [HTML4] section above. At > that point it will already be almost conformant to the 3261 syntax of a > token, except for the use of '&'. Then it needs to be encoded again, > which will take care of the ampersands, but which will re-encode the '%' > characters of the first encoding. [snip] DB> Your interpretation of the intent is correct. The postbody value is an application/x-www-form-urlencoded string which we subsequenty re-encode (the latter step affecting each & and % character). We will clarify the text that this is the case. Moreover, we'll be more specific and call out which parameter values are subject to this encoding step , namely vxml-url, the postbody token, and the json-value. > > Section 2.2: > > The Application Server SHOULD insert its own URI in the Record-Route > header so that it remains in the signaling path for subsequent > signaling related to the session. This is of particular importance > for call transfers so that upstream Application Servers or proxy > servers see signaling originating from the Application Server and not > the VoiceXML Media Server itself. > > I don't understand the purpose of the above. The SHOULD strength of this > requirement suggests to me an assumption of a particular operating > environment. In the general case, why should this be more than MAY > strength? DB> Actually, this paragraph is quite problematic. We shoudn't be mandating how the AS behaves (and indeed a B2BUA doesn't Record-Route anyway). This paragraph is also a hang over from before we recommended against using VoiceXML transfer features with application servers. We propose to delete it. > > Section 2.3: > > IMO the use of a media-less session is an entirely valid sip usage. The > only concern I might potentially have is if it were to catch some UA > unaware, because some UAs just aren't prepared to handle this case. But > the recommended usage here always puts the choice of doing this in the > hands of *other* UA, not the media server. So I see no problem. > > I do find it disconcerting that the initial invite and subsequent > reinvites are handled in different ways. For the initial one you stall > the VXML awaiting a media stream, but on subsequent ones you assume the > absence of a stream is equivalent to having a stream that doesn't send > anything. Why isn't the behavior consistent in these cases? If you need > to support both behaviors, then it might be better to explicit and > unique signaling for each. For instance, you might define that a media > stream with a=inactive or a=sendonly (from the client's perspective - > client putting media server "on hold") could be treated as the absence > of input but the absence of the stream means you should wait for a > stream to be negotiated. > DB> We're conscious of the inconsistency but we took a judgement call to live with it. Preparing a session is hugely valuable for latency hiding. However, to support this kind of pause/resume feature once the dialog is executing is not practical since VoiceXML has no concept of such semantics and it is difficult to implement especially when external speech recognition and synthesis systems are used and operate on their own timers without pausing capabilities. [snip] > In addition, the array's toString() function returns the full SIP > Request-URI. For example, assuming a Request-URI of sip:dialog@ > example.com;voicexml=http://example.com;obj={"x":1,"y":true} > then > > I don't believe the above URI is valid. The ',' '{' and '}' aren't > syntactically correct in a URI pvalue. You would need to escape them. DB> Good catch, will fix > > Section 2.6.2: > > IIUC, message (1) contains no offer, (5) contains an offer with media, > and (6) accepts the call but rejects the media. If so, then (9) will > most likely be invalid. To make it valid, the o-line from (8) needs to > be replaced with one consistent to that used in (6), with the version > number incremented. And if (5) has more m-lines than (8), then (9) needs > to be padded with extra (rejected) m-lines. DB> Good catch. The intent here is to that the similarly SDP messages share the same m- and a- lines only. We propose to update the diagram and perhaps using a prime to denote a derivative SDP message, e.g. [offer2'], and clarifying in the text. > > > Section 5.2: > > On receipt of the REFER request, the VoiceXML Media Server MUST issue > a provisional response, 100 Trying. The 202 Accepted response > indicates that the VoiceXML document has been fetched and parsed > correctly. The VoiceXML Media Server proceeds to place the outbound > INVITE and will execute the application after the ACK is sent. > > The rules of RFC 4320 need to be followed here. REFER is a non-invite > transaction and so the timing of the 100 must be as specified in 4320. > DB> Will fix > > In the call flow, the sending of the initial NOTIFY before the 202 for > the REFER, and especially before determining if REFER is going to > succeed or fail, is at best unusual and almost certainly incorrect. > Sending the NOTIFY and then sending a failure response would certainly > be incorrect. > > I think you have two choices: > > - wait until the get is complete before sending the NOTIFY, and probably > send it after the 202. > > - send a 202 for the REFER before doing the GET. Inform of a GET failure > via a NOTIFY. > DB> There is currently an ongoing thread on the list about whether we remove this feature (and hence section) altogether. For the sake of argument, I'll assume it stays, in which case we think option 2 is the most conventional (especially since most systems responds to the REFER instantaneously). A GET failure would be conveyed by a NOTIFY with a 500 Server Internal Failure sipfrag message (same status used for the INVITE case). > > Section 6.3: > > In the call flow I think you probably need another NOTIFY between > messages (6) and (7). Its potentially too long until (13). DB> This is correct but we note in the text "(provisional responses and NOTIFY messages corresponding to provisional responses have been omitted for clarity)" ------=_Part_449_18274007.1198282656223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Paul,

Thanks a lot for the review. Mark and I have discussed each of these and I've responded to the comments below.

Cheers,

Dave

[snip]

Section 2.1:

The ABNF of the URI seems excessively rigid in the ordering of
parameters - first the init-parameters, then the vxml-parameters, then
then any other uri-parameters. It also doesn't note that
'uri-parameters' is defined in 3261.


DB> Good observation - ordering of the parameters was never intended. Your proposal looks good. However, while looking over this again, we found another issue which crept in late in the process related to the addition of JSON support. Specifically, the problem is that it is impossible to differentiate where vxml-params end and uri-parameters begin and hence which parameter values to interpret as JSON values and which as plain strings. We propose a change to limit JSON values to just the named VoiceXML session variables 'ccxml' and 'aai' (these were the two variables for which JSON support was originally sought).

  dialog-parameters = *(";" dialog-parameter)

  dialog-parameter  = init-param / url-parameter ; defined in [RFC 3261]

  init-param        = ";" (dialog-param /
                           maxage-param /
                           maxstale-param /
                           method-param /
                           postbody-param /
                           ccxml-param /
                           aai-param)

  dialog-param      = "voicexml=" vxml-url ; vxml-url follows the URI
                                           ; syntax defined in [RFC3986]
  maxage-param      = "maxage=" 1*DIGIT

  maxstale-param    = "maxstale=" 1*DIGIT

  method-param      = "method=" ("get" / "post")

  postbody-param    = "postbody=" token

  ccxml-param       = "ccxml=" json-value

  aai-param         = "aai=" json-value

  json-value        =  false /
                       null /
                       true /
                       object /
                       array /
                       number /
                       string ; see RFC4627


I'm confused about postbody:

[snip]

The interaction between these two escaping rules seems potentially
confusing. I *think* when this is all put together it means that the
body must first be encoded according to the [HTML4] section above. At
that point it will already be almost conformant to the 3261 syntax of a
token, except for the use of '&'. Then it needs to be encoded again,
which will take care of the ampersands, but which will re-encode the '%'
characters of the first encoding.

[snip]

DB> Your interpretation of the intent is correct. The postbody value is an application/x-www-form-urlencoded string which we subsequenty re-encode (the latter step affecting each & and % character). We will clarify the text that this is the case. Moreover, we'll be more specific and call out which parameter values are subject to this encoding step , namely vxml-url, the postbody token, and the json-value.

Section 2.2:

   The Application Server SHOULD insert its own URI in the Record-Route
   header so that it remains in the signaling path for subsequent
   signaling related to the session.  This is of particular importance
   for call transfers so that upstream Application Servers or proxy
   servers see signaling originating from the Application Server and not
   the VoiceXML Media Server itself.

I don't understand the purpose of the above. The SHOULD strength of this
requirement suggests to me an assumption of a particular operating
environment. In the general case, why should this be more than MAY strength?

DB> Actually, this paragraph is quite problematic. We shoudn't be mandating how the AS behaves (and indeed a B2BUA doesn't Record-Route anyway). This paragraph is also a hang over from before we recommended against using VoiceXML transfer features with application servers. We propose to delete it.

Section 2.3:

IMO the use of a media-less session is an entirely valid sip usage. The
only concern I might potentially have is if it were to catch some UA
unaware, because some UAs just aren't prepared to handle this case. But
the recommended usage here always puts the choice of doing this in the
hands of *other* UA, not the media server. So I see no problem.

I do find it disconcerting that the initial invite and subsequent
reinvites are handled in different ways. For the initial one you stall
the VXML awaiting a media stream, but on subsequent ones you assume the
absence of a stream is equivalent to having a stream that doesn't send
anything. Why isn't the behavior consistent in these cases? If you need
to support both behaviors, then it might be better to explicit and
unique signaling for each. For instance, you might define that a media
stream with a=inactive or a=sendonly (from the client's perspective -
client putting media server "on hold") could be treated as the absence
of input but the absence of the stream means you should wait for a
stream to be negotiated.

DB> We're conscious of the inconsistency but we took a judgement call to live with it. Preparing a session is hugely valuable for latency hiding. However, to support this kind of pause/resume feature once the dialog is executing is not practical since VoiceXML has no concept of such semantics and it is difficult to implement especially when external speech recognition and synthesis systems are used and operate on their own timers without pausing capabilities. 

[snip]
      In addition, the array's toString() function returns the full SIP
      Request-URI.  For example, assuming a Request-URI of sip:dialog@
      example.com;voicexml=http://example.com;obj={"x":1,"y":true} then

I don't believe the above URI is valid. The ',' '{' and '}' aren't
syntactically correct in a URI pvalue. You would need to escape them.

DB> Good catch, will fix

Section 2.6.2:

IIUC, message (1) contains no offer, (5) contains an offer with media,
and (6) accepts the call but rejects the media. If so, then (9) will
most likely be invalid. To make it valid, the o-line from (8) needs to
be replaced with one consistent to that used in (6), with the version
number incremented. And if (5) has more m-lines than (8), then (9) needs
to be padded with extra (rejected) m-lines.

DB> Good catch. The intent here is to that the similarly SDP messages share the same m- and a- lines only. We propose to update the diagram and perhaps using a prime to denote a derivative SDP message, e.g. [offer2'], and clarifying in the text.


Section 5.2:

   On receipt of the REFER request, the VoiceXML Media Server MUST issue
   a provisional response, 100 Trying.  The 202 Accepted response
   indicates that the VoiceXML document has been fetched and parsed
   correctly.  The VoiceXML Media Server proceeds to place the outbound
   INVITE and will execute the application after the ACK is sent.

The rules of RFC 4320 need to be followed here. REFER is a non-invite
transaction and so the timing of the 100 must be as specified in 4320.

DB> Will fix

In the call flow, the sending of the initial NOTIFY before the 202 for
the REFER, and especially before determining if REFER is going to
succeed or fail, is at best unusual and almost certainly incorrect.
Sending the NOTIFY and then sending a failure response would certainly
be incorrect.

I think you have two choices:

- wait until the get is complete before sending the NOTIFY, and probably
send it after the 202.

- send a 202 for the REFER before doing the GET. Inform of a GET failure
via a NOTIFY.

DB> There is currently an ongoing thread on the list about whether we remove this feature (and hence section) altogether. For the sake of argument, I'll assume it stays, in which case we think option 2 is the most conventional (especially since most systems responds to the REFER instantaneously). A GET failure would be conveyed by a NOTIFY with a 500 Server Internal Failure sipfrag message (same status used for the INVITE case).
 

Section 6.3:

In the call flow I think you probably need another NOTIFY between
messages (6) and (7). Its potentially too long until (13).

DB> This is correct but we note in the text "(provisional responses and NOTIFY
   messages corresponding to provisional responses have been omitted for
   clarity)"

------=_Part_449_18274007.1198282656223-- --===============0472891568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0472891568==-- From sip-bounces@ietf.org Tue Jan 01 20:28:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9sOf-0006eh-30; Tue, 01 Jan 2008 20:27:53 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J8QvM-0001WD-Dn for sip-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 20:55:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J8QvM-0001W5-4N for sip@ietf.org; Fri, 28 Dec 2007 20:55:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8QtE-0000Ze-ND for sip@ietf.org; Fri, 28 Dec 2007 20:53:28 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8QtE-0004hh-Bf for sip@ietf.org; Fri, 28 Dec 2007 20:53:28 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lBT1rOFg011825 for ; Fri, 28 Dec 2007 19:53:24 -0600 (CST) Received: from cnexp01.bj.lucent.com ([135.252.8.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 19:53:24 -0600 Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.27]) by cnexp01.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Dec 2007 09:53:20 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 29 Dec 2007 09:52:48 +0800 Message-ID: <1F053F0D5C42184B9878C8D79BAE7D16295447@CNEXC1U03.BJ.LUCENT.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: about offer/answer model Thread-Index: AchJvYNPVwzIZLyzSCiJnDU55HtKLA== From: "Zhang, Rocky Fan Wen \(Rocky\)" To: X-OriginalArrivalTime: 29 Dec 2007 01:53:20.0434 (UTC) FILETIME=[96996120:01C849BD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-TMDA-Confirmed: Fri, 28 Dec 2007 20:55:40 -0500 X-Mailman-Approved-At: Tue, 01 Jan 2008 20:27:51 -0500 Subject: [Sip] about offer/answer model X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0225250617==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0225250617== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C849BD.9683E5AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C849BD.9683E5AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, =20 In the scenario of session timer, AS acts as the refresher and send a UPDATE to the endpoint without a SDP body, but the endpoint returns a 200 OK with a SDP. Does this action allowed? =20 Thanks in advance. =20 =20 Best Regards, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fanwen zhang FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D Tel: +86-532-88615493 Email:fanwenz@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C849BD.9683E5AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi, = all,
 
   In the = scenario of=20 session timer, AS acts as the refresher and send a UPDATE to the = endpoint=20 without a SDP body,
   but = the endpoint=20 returns a 200 OK with a SDP. Does this action=20 allowed?
  =20
   Thanks = in=20 advance.
 
 
Best Regards,
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fanwen zhang
FS5000 CPE IOT, Alcatel-Lucent = Qingdao,=20 R&D
Tel:=20 +86-532-88615493
Email:fanwenz@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
------_=_NextPart_001_01C849BD.9683E5AB-- --===============0225250617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0225250617==-- From sip-bounces@ietf.org Tue Jan 01 20:29:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9sPm-0006yI-Hb; Tue, 01 Jan 2008 20:29:02 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4Uuy-0007Ey-PO for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 00:23:00 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4Uuy-0007Eo-Fw for sip@ietf.org; Tue, 18 Dec 2007 00:23:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4UuI-00074I-LM for sip@ietf.org; Tue, 18 Dec 2007 00:22:18 -0500 Received: from itclus2.sea5.speakeasy.net ([72.1.141.56] helo=EXCHANGE-BE2.speakeasy.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4UuI-00047i-1T for sip@ietf.org; Tue, 18 Dec 2007 00:22:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Dec 2007 21:22:16 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INVITE after terminated dialog? Thread-Index: AchBNfSdslABBfwHRKqeaIPMhx+1OA== From: "Jane Jiang" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-TMDA-Confirmed: Tue, 18 Dec 2007 00:23:00 -0500 X-Mailman-Approved-At: Tue, 01 Jan 2008 20:29:00 -0500 Subject: [Sip] INVITE after terminated dialog? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0257386767==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0257386767== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84135.F44D76F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84135.F44D76F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 There is a weird situation with us: (1) A Linksys phone sends an INVITE out with incorrect destination TN. As a result, our application server will set up a call between the Linksys phone and an IVR (2) A user incorrectly hits the on-hold key, which is basically sending a re-INVITE to the IVR (3) Our server seems to have answered the re-INVITE with a BYE (4) The Linksys phone responds to the BYE with a 200 (5) Afterwards, the Linksys phone still thinks that its original re-INVITE has not been responded. So, it will keep resend re-INVITE =20 The consequence of these re-INVITEs is a registration migration, which we don't like. We have been trying to figure out which side is not following RFC 3261, the phone, the SBCs are wrong, or the application servers. =20 I am wondering: (A) Is it legal for a server to ignore the re-INVITE and respond with a BYE and has nothing in between? =20 (B) If a UA has responded to a BYE with 200, is it supposed to forget about the re-INVITE request that it has sent out and not try to resend the re-INVITE, assuming a dialog has already been terminated with the BYE/200 transaction? Maybe in another sentence, is it legal to send our re-INVITEs outside an dialog, even if these re-INVITEs are the repeats of an original in-dialog re-INVITE? =20 Thanks! =20 Jane =20 ------_=_NextPart_001_01C84135.F44D76F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
There = is a weird=20 situation with us:
(1) A = Linksys phone=20 sends an INVITE out with incorrect destination TN.  As a = result,=20 our application server will = set up a=20 call between the Linksys phone and an=20 IVR
(2) A user incorrectly hits the on-hold key, which is = basically sending a re-INVITE to the=20 IVR
(3) = Our=20 server seems to have = answered the re-INVITE with a = BYE
(4) = The Linksys=20 phone responds to the BYE = with a=20 200
(5) = Afterwards, the=20 Linksys phone still thinks that its original=20 re-INVITE has not been responded.  So, it will keep=20 resend re-INVITE
 
The = consequence of=20 these re-INVITEs is a registration = migration, which we don't like.  We have been trying to=20 figure out which side is not = following RFC=20 3261, the phone, the SBCs are wrong, or the application = servers.
 
I am=20 wondering:
(A) Is = it legal for=20 a server to ignore the re-INVITE = and=20 respond with a BYE and has nothing in = between?
 
(B) If = a UA has=20 responded to a BYE with 200, is it supposed to forget about the = re-INVITE=20 request that it has sent out and not try to resend the re-INVITE, = assuming a=20 dialog has already been terminated with the BYE/200 transaction?  = Maybe in=20 another sentence, is it legal to send our re-INVITEs outside an dialog, = even if=20 these re-INVITEs are the repeats of an original in-dialog=20 re-INVITE?
 
Thanks!
 
Jane
 
------_=_NextPart_001_01C84135.F44D76F8-- --===============0257386767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0257386767==-- From sip-bounces@ietf.org Tue Jan 01 21:34:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9tQI-000092-1N; Tue, 01 Jan 2008 21:33:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J9tQH-00008x-4e for sip-confirm+ok@megatron.ietf.org; Tue, 01 Jan 2008 21:33:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9tQG-00008p-GX for sip@ietf.org; Tue, 01 Jan 2008 21:33:36 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9tQG-0008OM-7w for sip@ietf.org; Tue, 01 Jan 2008 21:33:36 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Jan 2008 21:33:36 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m022XZ23001905; Tue, 1 Jan 2008 21:33:35 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m022XZgx004802; Wed, 2 Jan 2008 02:33:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jan 2008 21:33:35 -0500 Received: from [10.86.240.112] ([10.86.240.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jan 2008 21:33:35 -0500 Message-ID: <477AF7F8.2020000@cisco.com> Date: Tue, 01 Jan 2008 21:33:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Zhang, Rocky Fan Wen \(Rocky\)" Subject: Re: [Sip] about offer/answer model References: <1F053F0D5C42184B9878C8D79BAE7D16295447@CNEXC1U03.BJ.LUCENT.COM> In-Reply-To: <1F053F0D5C42184B9878C8D79BAE7D16295447@CNEXC1U03.BJ.LUCENT.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2008 02:33:35.0228 (UTC) FILETIME=[DF94B3C0:01C84CE7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=978; t=1199241216; x=1200105216; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20about=20offer/answer=20model |Sender:=20 |To:=20=22Zhang,=20Rocky=20Fan=20Wen=20\(Rocky\)=22=20; bh=c3xMg35kwQpGa7BcbLyv9NNQ5SOHTQpYR5DSCtV2E2k=; b=JXjoZ4mbOBr26vTAXj3zE6CdBC4NzDAvQSjym+vgUwp+tIFQo5RsvIYXC+ JVXV5l4CyJDbkxyVXcFijJ0JY7gx7941KWo2izHQOT/Y8xLqDlx+lW35fbVz oTcmaarHNL; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org No, its not allowed. Paul Zhang, Rocky Fan Wen (Rocky) wrote: > Hi, all, > > In the scenario of session timer, AS acts as the refresher and send a > UPDATE to the endpoint without a SDP body, > but the endpoint returns a 200 OK with a SDP. Does this action allowed? > > Thanks in advance. > > > Best Regards, > > =========================================== > Fanwen zhang > FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D > Tel: +86-532-88615493 > Email:fanwenz@alcatel-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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 02 13:55:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8jl-0004Jh-CI; Wed, 02 Jan 2008 13:54:45 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JA8jj-0004HR-IH for sip-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 13:54:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8jj-0004EH-3l for sip@ietf.org; Wed, 02 Jan 2008 13:54:43 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA8jh-0000yk-BQ for sip@ietf.org; Wed, 02 Jan 2008 13:54:43 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m02Isdvc019773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Jan 2008 12:54:40 -0600 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: <3C469C99-F17F-49D1-B5DE-862C638E2FE6@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "sip@ietf.org List" From: Dean Willis Date: Wed, 2 Jan 2008 12:54:27 -0600 X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 Subject: [Sip] Draft minutes, SIP at IETF 70 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'll get these on the various sites shortly. ------------- Draft Minutes, SIP at IETF 70 Edited by Dean Willis based on notes by Ben Campbell, Miguel Angel Garcia-Martin and Brian Rosen Session 1 ======== Topic: Agenda and Status led by Chairs Slides presented and included in proceedings Issue: How to deal with extensions in experimental RFCS like "e2m" Proposed that we change the process of RFC 3427 to allow experimental track RFCs to register SIP extension headers. Discussion concluded that using an "X-" prefix in the registry would be self-defeating. There are also concerns about setting the bar too low -- we want any registered extension headers fields to be both reasonable and well- documented. The group reached a consensus on making a change to RFC 3427 allowing any RFC produced by the SIP working group to register extension headers. Issue: Robert's fork-loop-fix draft Not enough people appear to have read the draft yet for us to have a strong sense of whether the changes satisfy issues raised in WGLC. The consensus is that the chairs shall conduct another short WGLC. Topic: Location Conveyance led by James Polk Slides presented and included in proceedings Issue: Should we have an error message to describe what's bad about the civic address data contained in a prior message? Several points were raised in discussion, including whether we have enough of an understanding of location validation to be able to do this sort of detailed response coding at this time. The current draft allows for a human-readable string, and this may suffice for current needs. Whether this is sufficient depends in large part on whether we expect automata to be able to respond to a a validation error, correct the location data, and resubmit it. There may also be the possible that the automata could parse the error response and ask a human a specific question, such as "What floor are you on?" if needed. No conclusion was reached in the meeting, and the author was asked to lead a discussion of the issue on the mailing list. Issue: What are the semantics of the "recipient" parameter in the Geolocation header? Debate centered on whether this parameter is a hint, a provider of context, or a binding constraint on authorization to access the location information. The discussion became somewhat heated. The working group did indicate a strong consensus to develop a protocol mechanism for location-based routing. Debate during the meeting session was inconclusive, and it was proposed that we have an ad-hoc breakout session on this topic. The ad-hoc session resolved to move this semantic into the geopriv object itself, and to send the work item for this back to GEOPRIV to complete. Topic: Info Harmful led by led by Eric Burger Slides presented and included in proceedings Discussion was deferred until after the presentation of the INFO Events draft. Topic: Info Events led by Christer Holmberg Slides presented and included in proceedings Issue: If an endpoint can receive an info package (i.e., indicates it can receive such events), does that mean it will do something useful with an event if it receives it? Discussion seems to indicate that each INFO event package will determine the requirements for that package, with the general trend being "only say you know it if you want it". So, event packages, where available, would be higher-priority than older techniques with less negotiation flexibility. Issue: If the other end doesn't understand an INFO event you want to send, what do you do? Discussion concluded that a node can only send events that the other side has indicated a willingness to receive, so if the other end doesn't understand something, don't send it. This may mean that event- dependent applications won't work, or that one might have to do something tricky like falling back to actually talking to the other party instead of sending events. Issue: Backward Compatibility Noted that in the bad-old-days of INFO, all backward compatibility was handled manually by configuration. That technique can still be used. However, for the ISUP and QSIG uses, we can provide for backward compatibility using Accept header fields as these payloads have MIME types that are not used in other contexts. Also noted that we need to consider these sort of backward compatibility issues in each event package. Issue: Do we want to enable transmission of user-to-user information in an INVITE initiated dialog? This was one of the arguments against dialogs of MESSAGE methods. Discussion indicated that we're probably OK with this for the class of things we seem to think will end up in INFO events. It was noted by a chair that there is little sense in trying to "protocol police" this sort of thing -- the requirement is just t make sure that the protocol allows the applications involved to understand what they're doing and not step on each other's extensions. Issue: Use cases? Whether DTMF is a convincing use case was discussed without conclusion. Noted that other SDOs appear to be developing things using INFO. This MAY be because INFO is the right thing, or it may be simply because they don't have to negotiate with IETF to use it, and that if we adjust INFO to encourage them to work with IETF, they might just find some other loophole like X-headers. Proposed that there are non-DTMF needs for end to end traffic, but that these needs may be better met by end-to-end sessions like MSRP. Of course, this raises the issue of negotiating the semantics of these end-to-end sessions, like "Why are you sending me these JPEG images in an MSRP session? What AM I supposed to do with them?", so there would still be a need for some sort of package definition. However, DTMF may be unique in being both signaling and media, and we might solve much of the problem by just finding a fix at the SIP level for DTMF and ignoring the remainder of the problem. Discussion on whether use cases could motivate the work. At one point, a poll by the chairs indicated that few of the people opposed to INFO events would be persuaded even if confronted with a large number of valid use cases. Issue: Registration policy. If we were to define INFO events, what would the IANA policy be on registering an INFO event package? Chair Dean Willis proposed that the policy be "specification required", given that our goal is not to police the architectures of everybody who wants to use SIP, but that we do need to make sure that the feature negotiation mechanism work well enough that conflicts are avoided. We really should NOT have to use SIP working group time to discuss whether or not some other SDO's use of their SIP-absed signaling channel is valid. Issue: Where to go from here? Noted that there ARE other SDOs actively engaged, and that we are not servcing the community well by giving no guidance. Eric Burger noted that the two drafts are not incompatible, and that the INFO events draft solves all of the "harmful" aspects of current INFO use noted in his draft. The meeting concluded with an agreement to further consider use cases, but no commitment to further action. (Note: subsequent discussion occurred on-list, shortly after the meeting session). Session 2 ======== Topic: Agenda and Status led by Chairs Slides presented and included in proceedings Discussion of Essential Corrections will be added to the agenda if time allows. The XCAP Diff event draft will be revised and submitted as draft-ietf- sip-xcapevent-00 Connection reuse was rescoped to allow some requests in the reverse direction and discourage connection reuse for virtual servers. Some further clarifications are needed. Topic: Outbound led by Rohan Mahy Slides presented and included in proceedings Issue: TCP Keepalive Current text removed. Noted that even if you use TCP keepalive, you still need to do the keepalives as specified in this draft. Issue: interaction with GRUU. Group seemed to indicate consensus on the proposal by Rohan for the 2nd option listed in the slides -- GRUU should check that an incoming REGISTER matches any Call-ID already registered by this device. This would appear to require a change in the GRUU document. Issue: What error does the registrar send if it gets a register with require: outbound but the edge proxy doesn't support outbound? Christer Holmberg suggested that most cases would need a 500-class. Jonathan Rosenberg noted that this depends on what might happen if the requested were to be retried. If it is always going to fail, the response would be in the 400 class. If success on retry is possible, a 500 might be more reasonable. Cullen Jennings noted that It is also important to consider what clients will do with the response. Adam Roach observed that a 420 response would make it hard to debug the problem from a client perspective, and that a new error code would be better. Jonathan suggested using a proxy require that the proxy would translate to require, but Rohan reminded us of prior discussion where we had decided this would not work. Christer concurred with Adam, saying that this problem is more general, essentially an "invalid path". The resolution is to develop a new 400 class response code indicating the problem with this path. Adam Roach volunteered to send text. Issue: How do subsequent in-dialog requests follow across an Outbound edge link? Proposed by Rohan that the Outbound proxy MUST record route if the top Route header has an :ob" parameter. Extended discussion followed, noting that this makes us dependent on proxies for mid-dialog requests, which has impacts on reliability designs. Francois Audet noted that the current text is hard to understand. Chairs conclude that the room seems to mostly support the resolution proposed by Rohan, but that the final text needs to be reviewed and agreed on-list. Issue: The "keep" parameter. Ted Hardie argued for keeping the text as-is. Aki Niemi argued in favor of deprecating the "keep" parameter, based on its lack of usefulness and potential to confuse people. Christer Holmberg suggested deprecating the parameter when used with an outbound proxy, but allowing it for non-outbound cases. Poll by chairs indicated strong consensus for removing the "keep" parameter. Issue: Replace timed-keepalive parameter with a new header Proposed by Aki that weuse a new header, such as "Flow-Timer" to be returned in register response. Noted by Rohan that this might fix the non-outbound case for keepalive. Christer questions this, as it is still necessary to know if keepalive is supported. Poll by chairs indicated strong consensus to define a new header for this purpose. Issue: Detecting client support for keepalives without "outbound" Proposed new option tag for client support, included by client in Supported. Poll by chairs indicated preference to consider this approach outside of the Outbound draft. Christer Holmberg may pursue a draft on this topic. Procedural point: Francois Audet has volunteered to act as the protocol shepherd for getting this draft through the process. Derek reminded Rohan to add text relating to the route construction issue. Derek will try to send text on this to Rohan. Topic: Resource Priority Header in Responses led by Janet Gunn Slides presented and included in proceedings Discussion centered on the role of the RPH header in a response and the assumptions underlying a network in which it would be useful. The key issue is that since SIP cannot challenge responses that if the response is not signed (as in SIP Identity) then there is no way to tell upstream where the RPH header came from. There may be no coupling between the proxy layer and the access network for media priority enforcement. Noted by EKR that given the security model, where the user is not trusted but all the proxy nodes are, that this requires integrity protection on the connections, with peer authentication. A proxy receiving a response with RPH has to know that it's getting this response from a trusted proxy and not somebody else. Several parties suggested that this sort of mechanism is more appropriate for a P-header with an applicability statement that explains the transitive trust model. Keith Drage, as chair, asked people to consider the stateless proxy use case from James' draft relative to the security assumptions, P- header concept, and authentication issues. Topic: Media Identity led by Dan Wing Slides presented and included in proceedings Issue: SBCs break 4474 because SDP signed by Identity is rewritten by SBC Francois observed that this problem may only occur when it is an SBC outside the domain of the Identity server that is doing the rewriting. Hannes suggested extending IDENTITY to be like DKIM, which can selectively sign pieces. General discussion revealed that most of the material in the signaling is problematic from a signature perspective. IP Addresses are essentially meaningless, especially across domain boundaries. Phone numbers are little better, with end-nodes having no real way to test assertions about them (and perhaps a service provided signature is the best we can do here). RFC 4474 already documents limitations with respect to telephone numbers. There seems to be an emerging thread of consensus here that what we need is some way to bind media to signaling -- that is, to by inspection of the media and the signaling be able to say with some level of certainty that they are related -- and specifically, to say "this media is a result of that signaling". Chairs noted that there is additional work required her to be able to frame this into the sort of requirement that could be added to a charter. Topic: DTLS Framework led by Jason Fischl Slides presented and included in proceedings Issue: 4474 for phone numbers We may be lacking documentation on when RFC 4474 does and does not work, and what security we get when using it with phone numbers. Jon Peterson seems to think that 4474 already offers this guidance. Jonathan Rosenberg disagrees and believes the text in 4474 is inadequate and more is needed. Consensus noted that even if we do need more here, it is outside of the scope of the DTLS framework. However, the framework should at least note the issue. Issue; Anonymity Agreed that text must be updated to say it does not break existing anonymity. Issue: Middle boxes. SBCs may block key exchange before 200 OK. This is not specific to DTLS-SRTP. Proposed by Christer that we at least mention this issue in the draft. RKR noted that much of this SBC difficulty should be documented in Brian's middlebox draft. Issue: SRTP/TCP Consensus: DTLS-SRTP over TCP rather than RTP over TLS. Issue: Priority for advancing. Chairs observed that an AVT document is dependent on this, making this a high priority to move along, However, the AVT chair reported that the AVT document is not as ready as we might have thought. Topic: Essential Corrections led by Keith Drage Slides presented and included in proceedings Issue: general intent of essential corrections We seem to have some disagreement as to the intent and value of the essential corrections process. The chairs restated the goal as being to batch together the updates to RFC 3261 so that readers do not have to look in many places to find the current "corrected" specification. Issue: record-route-fix Is this an essential correction or an enhancement? It does identify specific failure cases that occur if RFC 3261 is used as-is. The chairs noted that drafts making normative changes to a standards track draft need to be standards track themselves, not BCPs. However, BCPs would be appropriate for documents that, for example, argue for using one option in an an existing standards-track document over an alternative in that document. Robert argues that this fix is needed, although it would be acceptable to advance it individually rather than in the essential- corrections procss. Conclusion: robert and Jonathan are to go discuss this and come back with a recommendation. Issue: IPV6 ABNF error Consensus that this is an essential correction we would consider anything that behaves as per 3261 to be erroneous. Issue: 503 corrrection JDR argues that it is known that 3261 doesn't perform well in overload conditions, and that we have ongoing work to improve this behavior. Volker Hit concurs, noting that the overload team is still working to get better simulation results. Conclusion: We'll continue to discuss this document but not move towards WGLC yet. Issue: Mutual authentication Noted that there does seem to be a use case for this extension in IMS and cable networks, but that it probably doesn't meet the litmus test for an essential correction. Conclusion: It shall be discussed as an extension. Issue: invfix Conclusion: this is an essential correction. Author Robert Sparks is to revise for WGLC. Topic: INFO Chairs proposal is for Hadriel and Christer to continue their draft, rolling in the supporting motivation from Eric's draft. We will also discuss use cases for the INFO package model. if we don't find three agreeable use cases by the next meeting, we'll go ahead and publish Eric's "INFO Considered Harmful" draft so that there will be some firm guidance in RFC format. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 02 14:59:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA9jN-0001QZ-Ti; Wed, 02 Jan 2008 14:58:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JA9jL-0001Lt-Ul for sip-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 14:58:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JA9jL-0001Lk-LO for sip@ietf.org; Wed, 02 Jan 2008 14:58:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA9Jz-0007F1-J5 for sip@ietf.org; Wed, 02 Jan 2008 14:32:11 -0500 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA9Jy-0008RM-TR for sip@ietf.org; Wed, 02 Jan 2008 14:32:11 -0500 Received: by mu-out-0910.google.com with SMTP id i10so4136410mue.3 for ; Wed, 02 Jan 2008 11:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=jvG16aC6ndkybriEMzIEaxkKjuH8bBKYpZi2FrlHZqM=; b=PlaP9z0gH9c6DJQCoWZKWBieIWSTDTXJMYSmFy8a8YrsYH2Upi9DpRUGOW3a63Hzf1tY9WZ3NpDGyIfsOViziablMT3OfMZwnw7Nem1PfGsSPR432ruya1SXsyb3Q5ted8Skmphoby5i31kfSbkDjYrzImRJh7fZr583izcv5o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Xbbzw5k6+vgH+I1gae9UUQsSjceTYP3ZydS69KhVYTUVzSoLPZ8o5n8tSZmQaQnBluivk16FuVHXfOL5Danhp9RMHMXitQ+CT1fVHA77gKWfciEa9OTrib9RWOnsxM/5Vjlg6B7KZ7n3sGbdMwSRZLTuL/J10SXx6KhMm1awSwM= Received: by 10.78.204.1 with SMTP id b1mr6027969hug.73.1199302328998; Wed, 02 Jan 2008 11:32:08 -0800 (PST) Received: by 10.78.107.18 with HTTP; Wed, 2 Jan 2008 11:32:08 -0800 (PST) Message-ID: <7389c8a20801021132k3462841ct3b27ef8636fb6cca@mail.gmail.com> Date: Wed, 2 Jan 2008 17:32:08 -0200 From: "Nadya Zanon" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-TMDA-Confirmed: Wed, 02 Jan 2008 14:58:23 -0500 Subject: [Sip] I'm a SIP beginner X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1204688262==" Errors-To: sip-bounces@ietf.org --===============1204688262== Content-Type: multipart/alternative; boundary="----=_Part_26234_31273726.1199302328990" ------=_Part_26234_31273726.1199302328990 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello All, I'm a SIP beginner, probably my questions in the begin will be silly but I believe that you will understand me. I have two questions for now: 1) Are there some place where I can find a bunch of drafts for mapping of PSTN features on SIP? 2) Are ther some gateway and standard that maps SMS messages on SIP? I mean, are there some mapping from GSM for example to SIP? Thanks in advance, Nadya Zanon ------=_Part_26234_31273726.1199302328990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello All,
 
I'm a SIP beginner, probably my questions in the begin will be silly but I believe that you will understand me.
 
I have two questions for now:
 
1) Are there some place where I can find a bunch of drafts for mapping of PSTN features on SIP?
2) Are ther some gateway and standard that maps SMS messages on SIP? I mean, are there some mapping from GSM for example to SIP?
 
 
Thanks in advance,
 
Nadya Zanon
------=_Part_26234_31273726.1199302328990-- --===============1204688262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1204688262==-- From sip-bounces@ietf.org Wed Jan 02 22:17:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAGZd-0006tA-I9; Wed, 02 Jan 2008 22:16:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAGZc-0006sv-Vl for sip-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 22:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAGZc-0006sn-KM for sip@ietf.org; Wed, 02 Jan 2008 22:16:48 -0500 Received: from qmta01.emeryville.ca.mail.comcast.net ([76.96.30.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAGZc-0007ml-3S for sip@ietf.org; Wed, 02 Jan 2008 22:16:48 -0500 Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id YLhW1Y00K0lTkoC0A0fX00; Thu, 03 Jan 2008 03:16:47 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id YTGd1Y00G0umElk8Q00000; Thu, 03 Jan 2008 03:16:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=1uJyfwz8gFoA:10 a=9ADtd9WXbZC9uD0qkyQA:9 a=D72WbAklvw09pl7J47QA:7 a=W4yZHdP6yKHR1c-atV2WCWtEc68A:4 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m033Gj5k020876 for ; Wed, 2 Jan 2008 22:16:45 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m033GiGC020872; Wed, 2 Jan 2008 22:16:44 -0500 Date: Wed, 2 Jan 2008 22:16:44 -0500 Message-Id: <200801030316.m033GiGC020872@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (janej@hq.speakeasy.net) Subject: Re: [Sip] INVITE after terminated dialog? References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jane Jiang" Hi All, There is a weird situation with us: (1) A Linksys phone sends an INVITE out with incorrect destination TN. As a result, our application server will set up a call between the Linksys phone and an IVR (2) A user incorrectly hits the on-hold key, which is basically sending a re-INVITE to the IVR (3) Our server seems to have answered the re-INVITE with a BYE (4) The Linksys phone responds to the BYE with a 200 (5) Afterwards, the Linksys phone still thinks that its original re-INVITE has not been responded. So, it will keep resend re-INVITE The consequence of these re-INVITEs is a registration migration, which we don't like. We have been trying to figure out which side is not following RFC 3261, the phone, the SBCs are wrong, or the application servers. I am wondering: (A) Is it legal for a server to ignore the re-INVITE and respond with a BYE and has nothing in between? The server can legally send a request before responding to a request it has received. Indeed, it must be allowed to do so, as from the protocol point of view that action is indistinguishable from the network delaying the re-INVITE. However, the server remains obliged to send a response to the re-INVITE, as each request is a separate transaction that demands a response. In this case, 481 Dialog Usage Does Not Exist seems most appropriate. (B) If a UA has responded to a BYE with 200, is it supposed to forget about the re-INVITE request that it has sent out and not try to resend the re-INVITE, assuming a dialog has already been terminated with the BYE/200 transaction? In principle, the re-INVITE is a separate transaction and the UA should complete processing that transaction by re-sending to get a response (until the time-out). However, the server cannot enforce that (as it is possible that the network has lost all sends of the request), and if the UA decides that it no longer is concerned with the response the re-INVITE might get, it can give up resending the re-INVITE. Maybe in another sentence, is it legal to send our re-INVITEs outside an dialog, even if these re-INVITEs are the repeats of an original in-dialog re-INVITE? A re-INVITE is by definition within a dialog, since a re-INVITE is (by definition) an INVITE with a to-tag. However, if the INVITE dialog usage of the dialog has been terminated (by the server sending the BYE), the re-INVITE will fail, as you can't create a new INVITE dialog usage within a dialog that has had one which has been terminated. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 03 02:55:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAKuk-0007YA-Ig; Thu, 03 Jan 2008 02:54:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAKui-0007Y5-Nx for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 02:54:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAKui-0007Xx-BC for sip@ietf.org; Thu, 03 Jan 2008 02:54:52 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAKuh-0008TC-Td for sip@ietf.org; Thu, 03 Jan 2008 02:54:52 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m037orYL011351; Thu, 3 Jan 2008 08:50:53 +0100 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Jan 2008 08:54:49 +0100 Message-ID: <477C94C6.9000904@alcatel-lucent.fr> Date: Thu, 03 Jan 2008 08:54:46 +0100 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Nadya Zanon Subject: Re: [Sip] I'm a SIP beginner References: <7389c8a20801021132k3462841ct3b27ef8636fb6cca@mail.gmail.com> In-Reply-To: <7389c8a20801021132k3462841ct3b27ef8636fb6cca@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2008 07:54:49.0512 (UTC) FILETIME=[EA5CCA80:01C84DDD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Nadya Zanon wrote: > > 1) Are there some place where I can find a bunch of drafts for mapping > of PSTN features on SIP? If, by 'PSTN features', you mean "SIP services" (e.g.: call fowarding, completion, transfers and so on) you MAY have a look at BLISS working group (http://ietf.org/html.charters/bliss-charter.html), and on the "SIP services guide" individual draft tentative: http://tools.ietf.org/html/draft-ligot-bliss-sip-services-guide This is a work in progress, but it already contains many references to IETF and non-IETF specs (ETSI/TISPAN in particular). Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 03 03:39:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JALb7-0004AP-SL; Thu, 03 Jan 2008 03:38:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JALb6-0004AK-GI for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 03:38:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JALb6-0004AA-4W for sip@ietf.org; Thu, 03 Jan 2008 03:38:40 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JALb5-0000w9-Jh for sip@ietf.org; Thu, 03 Jan 2008 03:38:40 -0500 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1199349516!7948664!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 3161 invoked from network); 3 Jan 2008 08:38:36 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-153.messagelabs.com with SMTP; 3 Jan 2008 08:38:36 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m038cUQT013670 for ; Thu, 3 Jan 2008 01:38:36 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m038cUoR001095 for ; Thu, 3 Jan 2008 02:38:30 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m038cS39001052 for ; Thu, 3 Jan 2008 02:38:29 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] I'm a SIP beginner Date: Thu, 3 Jan 2008 16:38:26 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B052CC13E@ZMY16EXM66.ds.mot.com> In-Reply-To: <7389c8a20801021132k3462841ct3b27ef8636fb6cca@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I'm a SIP beginner Thread-Index: AchNee5Xdck1P+zfQ92Y0wH0jdOtPAAac8gQ From: "Avasarala Ranjit-A20990" To: "Nadya Zanon" , X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0304967319==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0304967319== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84DE4.0289E986" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84DE4.0289E986 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nadya =20 u can have a look at RFC 3398 for mapping of ISUP protocol to SIP. =20 Regards Ranjit ________________________________ From: Nadya Zanon [mailto:nadya.zanon@gmail.com]=20 Sent: Thursday, January 03, 2008 1:02 AM To: sip@ietf.org Subject: [Sip] I'm a SIP beginner Hello All, =20 I'm a SIP beginner, probably my questions in the begin will be silly but I believe that you will understand me. =20 I have two questions for now: =20 1) Are there some place where I can find a bunch of drafts for mapping of PSTN features on SIP? 2) Are ther some gateway and standard that maps SMS messages on SIP? I mean, are there some mapping from GSM for example to SIP? =20 =20 Thanks in advance, =20 Nadya Zanon ------_=_NextPart_001_01C84DE4.0289E986 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nadya
 
u can have a look at RFC 3398 for mapping of = ISUP protocol=20 to SIP.
 
Regards
Ranjit

From: Nadya Zanon = [mailto:nadya.zanon@gmail.com]=20
Sent: Thursday, January 03, 2008 1:02 AM
To:=20 sip@ietf.org
Subject: [Sip] I'm a SIP = beginner

Hello All,
 
I'm a SIP beginner, probably my questions in the begin will be = silly but I=20 believe that you will understand me.
 
I have two questions for now:
 
1) Are there some place where I can find a bunch of drafts for = mapping of=20 PSTN features on SIP?
2) Are ther some gateway and standard that maps SMS messages on = SIP? I=20 mean, are there some mapping from GSM for example to SIP?
 
 
Thanks in advance,
 
Nadya Zanon
------_=_NextPart_001_01C84DE4.0289E986-- --===============0304967319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0304967319==-- From sip-bounces@ietf.org Thu Jan 03 08:09:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAPnz-0006Ui-K0; Thu, 03 Jan 2008 08:08:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAPny-0006Ub-C6 for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 08:08:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAPny-0006US-24 for sip@ietf.org; Thu, 03 Jan 2008 08:08:14 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAPnv-0007Mx-RO for sip@ietf.org; Thu, 03 Jan 2008 08:08:14 -0500 Received: by nf-out-0910.google.com with SMTP id d21so368914nfb.39 for ; Thu, 03 Jan 2008 05:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=P0j/TOcLDrDCRfzDQFiL6bbDDxoj8gmFBozDQLlGVis=; b=B4hrICcb+LuecesjRS0t0uPQ/cbLfJOOK0l6Ir9Qy+B1u4Xhbx6MDO0R373Q0mnxkH55qj6viW2e8x5xjK1xI5i8u3h7wSzrYwhHHsfBDpEYKCaiJQbuB+MuA6hFjzeM5dE597AdaLSEyEtudUnOgt4vhSUFGjAjIGfFY0k/Cds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=lM0nCl3liWNBeRReLYzfq5e23fnANYYSIgMhLcACCA2Cp/Es8TW0+kCBlp1nafLid/ETtJ/rRDe7Yl5i+zyuXTpzXBjIo4C5Un08FcpUHTz3khZrur+n4FtlYrtE2IisWFBHGsw4XsnbX1yS5DwxopA155womP3ADNcgcFsAVc4= Received: by 10.78.138.6 with SMTP id l6mr18013664hud.32.1199365690742; Thu, 03 Jan 2008 05:08:10 -0800 (PST) Received: by 10.78.107.18 with HTTP; Thu, 3 Jan 2008 05:08:10 -0800 (PST) Message-ID: <7389c8a20801030508i750841ao467643fd58cc67de@mail.gmail.com> Date: Thu, 3 Jan 2008 11:08:10 -0200 From: "Nadya Zanon" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] That is the future X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0323585038==" Errors-To: sip-bounces@ietf.org --===============0323585038== Content-Type: multipart/alternative; boundary="----=_Part_28909_24102685.1199365690735" ------=_Part_28909_24102685.1199365690735 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello All, Thanks for the all answers I received. They are very useful. I have another question, what is intended as the future of SIP and telephony? I mean the development of gateways will still be developed and the analog telephony will still be alive or the complete the replacement of the analog telephony by SIP. In the PBX world, if SIP pbx are connected directly to "SIP trunks", are there differences between the end point SIP and the SIP from the carrier? I have heard about SIP-T. Is there some relation with that? Thanks. Nadya Zanon ------=_Part_28909_24102685.1199365690735 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello All,
 
Thanks for the all answers I received. They are very useful.
 
I have another question, what is intended as the future of SIP and telephony?
I mean the development of gateways will still be developed and the analog telephony will still be alive or the complete the replacement of the analog telephony by SIP.
 
In the PBX world, if  SIP pbx are connected directly to "SIP trunks",  are there differences between the end point SIP and the SIP from the carrier? I have heard about SIP-T. Is there some relation with that?
 
 
Thanks.
 
Nadya Zanon
------=_Part_28909_24102685.1199365690735-- --===============0323585038== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0323585038==-- From sip-bounces@ietf.org Thu Jan 03 11:32:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JASyw-0000Cv-AL; Thu, 03 Jan 2008 11:31:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JASyv-0000Ck-2e for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 11:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JASyu-0000Cb-Jo for sip@ietf.org; Thu, 03 Jan 2008 11:31:44 -0500 Received: from smtp1.twtelecom.com ([168.215.22.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JASys-00026i-A0 for sip@ietf.org; Thu, 03 Jan 2008 11:31:44 -0500 Received: from SRVMSXMB1.ad.twtelecom.com ([10.1.34.20]) by srvmsxsmtp2.ad.twtelecom.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 09:31:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jan 2008 09:31:40 -0700 Message-ID: <11669E22A15393479F3066E8C3345491041B47E3@SRVMSXMB1.ad.twtelecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I am also a beginner with SIP Thread-Index: AchOJh4oDs46H9NGRI2t7V/fdec+Cw== From: "Farnham, Bruce" To: X-OriginalArrivalTime: 03 Jan 2008 16:31:40.0434 (UTC) FILETIME=[1E4FF720:01C84E26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Sip] I am also a beginner with SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1145646615==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1145646615== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84E26.1E22B5C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84E26.1E22B5C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been looking for some time for an RFC or specification that=0D details the mapping of SIP to Q.931. Does anyone know if such a=0D document exists? Thanks in advance, Bruce Farnham Time Warner Telecom The content contained in this electronic message is not intended to constitute formation of a contract binding TWTC. TWTC will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone. ------_=_NextPart_001_01C84E26.1E22B5C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am also a beginner with SIP

Hello,

I have been looking for= some time for an RFC or specification that
details the mapping of= SIP to Q.931. Does anyone know if such a
document exists?

Thanks in advance,

Bruce Farnham
Time Warner= Telecom

The content= contained in this electronic message is not intended to
constitute formation of a contract binding TWTC. TWTC will be
contractually bound only upon execution, by an authorized officer, of
a contract including agreed terms and conditions or by express
application of its tariffs.

This message is intended only for the use of the individual or entity
to which it is addressed. If the reader of this message is not the
intended recipient, or the employee or agent responsible for
delivering the message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the sender of this E-Mail or by telephone.
------_=_NextPart_001_01C84E26.1E22B5C8-- --===============1145646615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1145646615==-- From sip-bounces@ietf.org Thu Jan 03 12:27:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATqf-0001aw-SZ; Thu, 03 Jan 2008 12:27:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JATqd-0001ar-UK for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 12:27:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATqd-0001Z5-Fl for sip@ietf.org; Thu, 03 Jan 2008 12:27:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JATqb-0004Av-E3 for sip@ietf.org; Thu, 03 Jan 2008 12:27:15 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m03HRBTi027298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 3 Jan 2008 11:27:12 -0600 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: <7A5F403E-D25B-44CB-BAEE-C8BD2418443E@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "sip@ietf.org List" From: Dean Willis Date: Thu, 3 Jan 2008 11:26:59 -0600 X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Subject: [Sip] Revised minutes, SIP at IETF 70 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James Polk pointed out I forgot to include the breakout session we had on Location Conveyance. I've added this to the minutes. Copies of these minutes are also posted in the iETF Proceedings and in the SIP WIKI on the Softarmor site. Please point out any more issues. Revised minutes follow: Minutes, SIP at IETF 70 Edited by Dean Willis based on notes by Ben Campbell, Miguel Angel Garcia-Martin and Brian Rosen Session 1 ======== Topic: Agenda and Status led by Chairs Slides presented and included in proceedings Issue: How to deal with extensions in experimental RFCS like "e2m" Proposed that we change the process of RFC 3427 to allow experimental track RFCs to register SIP extension headers. Discussion concluded that using an "X-" prefix in the registry would be self-defeating. There are also concerns about setting the bar too low -- we want any registered extension headers fields to be both reasonable and well-documented. The group reached a consensus on making a change to RFC 3427 allowing any RFC produced by the SIP working group to register extension headers. Issue: Robert's fork-loop-fix draft Not enough people appear to have read the draft yet for us to have a strong sense of whether the changes satisfy issues raised in WGLC. The consensus is that the chairs shall conduct another short WGLC. Topic: Location Conveyance led by James Polk Slides presented and included in proceedings Issue: Should we have an error message to describe what's bad about the civic address data contained in a prior message? Several points were raised in discussion, including whether we have enough of an understanding of location validation to be able to do this sort of detailed response coding at this time. The current draft allows for a human-readable string, and this may suffice for current needs. Whether this is sufficient depends in large part on whether we expect automata to be able to respond to a a validation error, correct the location data, and resubmit it. There may also be the possible that the automata could parse the error response and ask a human a specific question, such as "What floor are you on?" if needed. No conclusion was reached in the meeting, and the author was asked to lead a discussion of the issue on the mailing list. Issue: What are the semantics of the "recipient" parameter in the Geolocation header? Debate centered on whether this parameter is a hint, a provider of context, or a binding constraint on authorization to access the location information. The discussion became somewhat heated. The working group did indicate a strong consensus to develop a protocol mechanism for location-based routing. Debate during the meeting session was inconclusive, and it was proposed that we have an ad-hoc breakout session on this topic. The ad-hoc session resolved to move this semantic into the geopriv object itself, and to send the work item for this back to GEOPRIV to complete. Issue: Are the error codes proposed too complex or too granular? Debate centered on whether the error codes helped users or automata recover from correctable conditions or are intended for post mortem debugging. Debate was extensive, with no immediate consensus forthcoming, so this topic was also deferred to the the breakout session. The breakout session resulted in a consensus on restructuring the error response codes. Minutes of this session are included later in this document. Topic: Info Harmful led by led by Eric Burger Slides presented and included in proceedings Discussion was deferred until after the presentation of the INFO Events draft. Topic: Info Events led by Christer Holmberg Slides presented and included in proceedings Issue: If an endpoint can receive an info package (i.e., indicates it can receive such events), does that mean it will do something useful with an event if it receives it? Discussion seems to indicate that each INFO event package will determine the requirements for that package, with the general trend being "only say you know it if you want it". So, event packages, where available, would be higher-priority than older techniques with less negotiation flexibility. Issue: If the other end doesn't understand an INFO event you want to send, what do you do? Discussion concluded that a node can only send events that the other side has indicated a willingness to receive, so if the other end doesn't understand something, don't send it. This may mean that event-dependent applications won't work, or that one might have to do something tricky like falling back to actually talking to the other party instead of sending events. Issue: Backward Compatibility Noted that in the bad-old-days of INFO, all backward compatibility was handled manually by configuration. That technique can still be used. However, for the ISUP and QSIG uses, we can provide for backward compatibility using Accept header fields as these payloads have MIME types that are not used in other contexts. Also noted that we need to consider these sort of backward compatibility issues in each event package. Issue: Do we want to enable transmission of user-to-user information in an INVITE initiated dialog? This was one of the arguments against dialogs of MESSAGE methods. Discussion indicated that we're probably OK with this for the class of things we seem to think will end up in INFO events. It was noted by a chair that there is little sense in trying to "protocol police" this sort of thing -- the requirement is just t make sure that the protocol allows the applications involved to understand what they're doing and not step on each other's extensions. Issue: Use cases? Whether DTMF is a convincing use case was discussed without conclusion. Noted that other SDOs appear to be developing things using INFO. This MAY be because INFO is the right thing, or it may be simply because they don't have to negotiate with IETF to use it, and that if we adjust INFO to encourage them to work with IETF, they might just find some other loophole like X-headers. Proposed that there are non-DTMF needs for end to end traffic, but that these needs may be better met by end-to-end sessions like MSRP. Of course, this raises the issue of negotiating the semantics of these end-to-end sessions, like "Why are you sending me these JPEG images in an MSRP session? What AM I supposed to do with them?", so there would still be a need for some sort of package definition. However, DTMF may be unique in being both signaling and media, and we might solve much of the problem by just finding a fix at the SIP level for DTMF and ignoring the remainder of the problem. Discussion on whether use cases could motivate the work. At one point, a poll by the chairs indicated that few of the people opposed to INFO events would be persuaded even if confronted with a large number of valid use cases. Issue: Registration policy. If we were to define INFO events, what would the IANA policy be on registering an INFO event package? Chair Dean Willis proposed that the policy be "specification required", given that our goal is not to police the architectures of everybody who wants to use SIP, but that we do need to make sure that the feature negotiation mechanism work well enough that conflicts are avoided. We really should NOT have to use SIP working group time to discuss whether or not some other SDO's use of their SIP-absed signaling channel is valid. Issue: Where to go from here? Noted that there ARE other SDOs actively engaged, and that we are not servicing the community well by giving no guidance. Eric Burger noted that the two drafts are not incompatible, and that the INFO events draft solves all of the "harmful" aspects of current INFO use noted in his draft. The meeting concluded with an agreement to further consider use cases, but no commitment to further action. (Note: subsequent discussion occurred on-list, shortly after the meeting session). Session 2 ======== Topic: Agenda and Status led by Chairs Slides presented and included in proceedings Discussion of Essential Corrections will be added to the agenda if time allows. The XCAP Diff event draft will be revised and submitted as draft-ietf-sip-xcapevent-00 Connection reuse was rescoped to allow some requests in the reverse direction and discourage connection reuse for virtual servers. Some further clarifications are needed. Topic: Outbound led by Rohan Mahy Slides presented and included in proceedings Issue: TCP Keepalive Current text removed. Noted that even if you use TCP keepalive, you still need to do the keepalives as specified in this draft. Issue: interaction with GRUU. Group seemed to indicate consensus on the proposal by Rohan for the 2nd option listed in the slides -- GRUU should check that an incoming REGISTER matches any Call-ID already registered by this device. This would appear to require a change in the GRUU document. Issue: What error does the registrar send if it gets a register with require: outbound but the edge proxy doesn't support outbound? Christer Holmberg suggested that most cases would need a 500-class. Jonathan Rosenberg noted that this depends on what might happen if the requested were to be retried. If it is always going to fail, the response would be in the 400 class. If success on retry is possible, a 500 might be more reasonable. Cullen Jennings noted that It is also important to consider what clients will do with the response. Adam Roach observed that a 420 response would make it hard to debug the problem from a client perspective, and that a new error code would be better. Jonathan suggested using a proxy require that the proxy would translate to require, but Rohan reminded us of prior discussion where we had decided this would not work. Christer concurred with Adam, saying that this problem is more general, essentially an "invalid path". The resolution is to develop a new 400 class response code indicating the problem with this path. Adam Roach volunteered to send text. Issue: How do subsequent in-dialog requests follow across an Outbound edge link? Proposed by Rohan that the Outbound proxy MUST record route if the top Route header has an :ob" parameter. Extended discussion followed, noting that this makes us dependent on proxies for mid-dialog requests, which has impacts on reliability designs. Francois Audet noted that the current text is hard to understand. Chairs conclude that the room seems to mostly support the resolution proposed by Rohan, but that the final text needs to be reviewed and agreed on-list. Issue: The "keep" parameter. Ted Hardie argued for keeping the text as-is. Aki Niemi argued in favor of deprecating the "keep" parameter, based on its lack of usefulness and potential to confuse people. Christer Holmberg suggested deprecating the parameter when used with an outbound proxy, but allowing it for non-outbound cases. Poll by chairs indicated strong consensus for removing the "keep" parameter. Issue: Replace timed-keepalive parameter with a new header Proposed by Aki that weuse a new header, such as "Flow-Timer" to be returned in register response. Noted by Rohan that this might fix the non-outbound case for keepalive. Christer questions this, as it is still necessary to know if keepalive is supported. Poll by chairs indicated strong consensus to define a new header for this purpose. Issue: Detecting client support for keepalives without "outbound" Proposed new option tag for client support, included by client in Supported. Poll by chairs indicated preference to consider this approach outside of the Outbound draft. Christer Holmberg may pursue a draft on this topic. Procedural point: Francois Audet has volunteered to act as the protocol shepherd for getting this draft through the process. Derek reminded Rohan to add text relating to the route construction issue. Derek will try to send text on this to Rohan. Topic: Resource Priority Header in Responses led by Janet Gunn Slides presented and included in proceedings Discussion centered on the role of the RPH header in a response and the assumptions underlying a network in which it would be useful. The key issue is that since SIP cannot challenge responses that if the response is not signed (as in SIP Identity) then there is no way to tell upstream where the RPH header came from. There may be no coupling between the proxy layer and the access network for media priority enforcement. Noted by EKR that given the security model, where the user is not trusted but all the proxy nodes are, that this requires integrity protection on the connections, with peer authentication. A proxy receiving a response with RPH has to know that it's getting this response from a trusted proxy and not somebody else. Several parties suggested that this sort of mechanism is more appropriate for a P-header with an applicability statement that explains the transitive trust model. Keith Drage, as chair, asked people to consider the stateless proxy use case from James' draft relative to the security assumptions, P-header concept, and authentication issues. Topic: Media Identity led by Dan Wing Slides presented and included in proceedings Issue: SBCs break 4474 because SDP signed by Identity is rewritten by SBC Francois observed that this problem may only occur when it is an SBC outside the domain of the Identity server that is doing the rewriting. Hannes suggested extending IDENTITY to be like DKIM, which can selectively sign pieces. General discussion revealed that most of the material in the signaling is problematic from a signature perspective. IP Addresses are essentially meaningless, especially across domain boundaries. Phone numbers are little better, with end-nodes having no real way to test assertions about them (and perhaps a service provided signature is the best we can do here). RFC 4474 already documents limitations with respect to telephone numbers. There seems to be an emerging thread of consensus here that what we need is some way to bind media to signaling -- that is, to by inspection of the media and the signaling be able to say with some level of certainty that they are related -- and specifically, to say "this media is a result of that signaling". Chairs noted that there is additional work required her to be able to frame this into the sort of requirement that could be added to a charter. Topic: DTLS Framework led by Jason Fischl Slides presented and included in proceedings Issue: 4474 for phone numbers We may be lacking documentation on when RFC 4474 does and does not work, and what security we get when using it with phone numbers. Jon Peterson seems to think that 4474 already offers this guidance. Jonathan Rosenberg disagrees and believes the text in 4474 is inadequate and more is needed. Consensus noted that even if we do need more here, it is outside of the scope of the DTLS framework. However, the framework should at least note the issue. Issue; Anonymity Agreed that text must be updated to say it does not break existing anonymity. Issue: Middle boxes. SBCs may block key exchange before 200 OK. This is not specific to DTLS-SRTP. Proposed by Christer that we at least mention this issue in the draft. EKR noted that much of this SBC difficulty should be documented in Brian's middlebox draft. Issue: SRTP/TCP Consensus: DTLS-SRTP over TCP rather than RTP over TLS. Issue: Priority for advancing. Chairs observed that an AVT document is dependent on this, making this a high priority to move along, However, the AVT chair reported that the AVT document is not as ready as we might have thought. Topic: Essential Corrections led by Keith Drage Slides presented and included in proceedings Issue: general intent of essential corrections We seem to have some disagreement as to the intent and value of the essential corrections process. The chairs restated the goal as being to batch together the updates to RFC 3261 so that readers do not have to look in many places to find the current "corrected" specification. Issue: record-route-fix Is this an essential correction or an enhancement? It does identify specific failure cases that occur if RFC 3261 is used as-is. The chairs noted that drafts making normative changes to a standards track draft need to be standards track themselves, not BCPs. However, BCPs would be appropriate for documents that, for example, argue for using one option in an an existing standards-track document over an alternative in that document. Robert argues that this fix is needed, although it would be acceptable to advance it individually rather than in the essential-corrections procss. Conclusion: robert and Jonathan are to go discuss this and come back with a recommendation. Issue: IPV6 ABNF error Consensus that this is an essential correction we would consider anything that behaves as per 3261 to be erroneous. Issue: 503 corrrection JDR argues that it is known that 3261 doesn't perform well in overload conditions, and that we have ongoing work to improve this behavior. Volker Hit concurs, noting that the overload team is still working to get better simulation results. Conclusion: We'll continue to discuss this document but not move towards WGLC yet. Issue: Mutual authentication Noted that there does seem to be a use case for this extension in IMS and cable networks, but that it probably doesn't meet the litmus test for an essential correction. Conclusion: It shall be discussed as an extension. Issue: invfix Conclusion: this is an essential correction. Author Robert Sparks is to revise for WGLC. Topic: INFO Chairs proposal is for Hadriel and Christer to continue their draft, rolling in the supporting motivation from Eric's draft. We will also discuss use cases for the INFO package model. if we don't find three agreeable use cases by the next meeting, we'll go ahead and publish Eric's "INFO Considered Harmful" draft so that there will be some firm guidance in RFC format. Session: Location Ad-Hoc ======================== An additional break-out session was held to discuss issues related to location conveyance and SIP, due to the failure to reach consensus on key issues during the regular session. Notes reported by Dean Willis Session chaired by Keith Drage Note-Well reviewed Discussion led by James POlk Slides presented Issue: Error codes in Geolocation-Error header Issues raised in SIP meeting include general sense that current error codes are just "too much" and should be reduced. Discussion of actionable vs. diagnostic errors ensued (started by James Winterbottom). Are the text strings fixed so that they can be processed by automata? Are we doing trend analysis or trying to make a call succeed that was failing? Comment by Henning Schulzrinne: Not really a question of whether 14 or 17 is the right number, but as to whether the civic address (CA) type information is appropriately included in the responses. Just including a CA type doesn't help solve the problem and may confuse the situation. Robots cannot usefully "fix" defective CA information, but require human interaction. I fear that the software will say "A1 and A7 are wrong" and the user will have no idea what to do. Response: Do you want to be able to say things like "The city field was missing and we need it." We could put this in the current draft for now. Counteproposal: We should leave CA types out for now and add them back in only if experience shows that they would have been useful. It's better to drop it now. We seem to have a consensus to delete the CA type information from error responses. As for other error codes, EKR suggests that those that are repairable by automata be included. Henning agrees, suggesting we also have one error code for human-fixable errors that can be communicated in text. Ted Hardie categorizes errors in 3 groups : 1) Same things that might work later, 2) vague "something you gave me is wrong", 3) bit-toggleable "permission" errors. Possibly a 4th class, "things an automata can fix", like refreshing its location calc and resending. Noted that SIP "Accept-Language" mechanism provides the human-language negotiation mechanism. Poll: does anybody have issues with Ted's plan? Mostly agreed: James will revisit. Issue: Recipient= Henning discussed differences between URN routing and URI routing in the presence of a location body. He has concerns that it might not be possible to make a reasonable determination in an implementation and this has lawsuit potential. Ted counter-argues that this was concluded in GEOPRIV. Massive debate ensued. Proposed: Easy solution for SIP working group is to move the functionality formally known as "recipient =" out of SIP and into PIDF-LO as a routing-allowed flag. This will require deleting the subject from the SIP draft and creating a new GEOPRIV draft. Jon Peterson volunteered to write the GEOPRIV draft. NOTE: The GEOPRIV draft will require careful definition of "retransmission" so as to not interact with the fact that SIP proxies operate by retransmitting SIP requests. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 03 13:08:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUTl-0006gX-CT; Thu, 03 Jan 2008 13:07:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAUTk-0006Xv-B2 for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 13:07:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUTj-0006WN-JU for sip@ietf.org; Thu, 03 Jan 2008 13:07:39 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAUTi-000564-VB for sip@ietf.org; Thu, 03 Jan 2008 13:07:39 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m03I7Pe5007292; Thu, 3 Jan 2008 12:07:37 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 12:07:33 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 19:07:31 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] That is the future Date: Thu, 3 Jan 2008 19:07:30 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001ABF78B@DEEXC1U01.de.lucent.com> In-Reply-To: <7389c8a20801030508i750841ao467643fd58cc67de@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] That is the future Thread-index: AchOCcrgLvJv72zEQx+uepnhqFklQgAJ9WaA References: <7389c8a20801030508i750841ao467643fd58cc67de@mail.gmail.com> From: "DRAGE, Keith \(Keith\)" To: "Nadya Zanon" , X-OriginalArrivalTime: 03 Jan 2008 18:07:31.0744 (UTC) FILETIME=[825C3A00:01C84E33] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is no relationship between IP-PBX interconnection and SIP-T unless = you need to interwork with SS7 as part of this process. =20 You can find work on interconnection of IP-PBX to public SIP networks in = the SIP forum, and in ETSI TISPAN. The SIP Forum work is at: http://www.sipforum.org/content/view/290/290/ =20 The ETSI TISPAN work is still in progress (except first document below = which is complete), but is publically available at: =20 http://portal.etsi.org/docbox/TISPAN/Open/NGN_LATEST_DRAFTS/RELEASE2/ =20 and take whatever is the latest version of: =20 01047 02040 02041 02042 =20 =20 Regards Keith=20 =20 ________________________________ From: Nadya Zanon [mailto:nadya.zanon@gmail.com]=20 Sent: Thursday, January 03, 2008 1:08 PM To: sip@ietf.org Subject: [Sip] That is the future =09 =09 Hello All, =20 Thanks for the all answers I received. They are very useful. =20 I have another question, what is intended as the future of SIP and = telephony? I mean the development of gateways will still be developed and the = analog telephony will still be alive or the complete the replacement of = the analog telephony by SIP. =20 In the PBX world, if SIP pbx are connected directly to "SIP trunks", = are there differences between the end point SIP and the SIP from the = carrier? I have heard about SIP-T. Is there some relation with that?=20 =20 =20 Thanks. =20 Nadya Zanon _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 03 13:58:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVGH-0007bx-Jx; Thu, 03 Jan 2008 13:57:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAVGG-0007be-Dy for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 13:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVGG-0007bT-3l for sip@ietf.org; Thu, 03 Jan 2008 13:57:48 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAVGF-00051Q-Iy for sip@ietf.org; Thu, 03 Jan 2008 13:57:48 -0500 Received: by fg-out-1718.google.com with SMTP id 16so3398383fgg.41 for ; Thu, 03 Jan 2008 10:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=cGk+Nu4rEUSVZZA9cyGSuqJvmo6Rr/sqqEPfK0qcFPE=; b=xNKTRopeejXXFzgAMoGQAbfnSLEHhXOn2ADiNh0nYeFDQYmJJhNLvnygZ3X1bnytsb1jJEL6PNVxfcYWPmy5APyffQWyjMBLmTYGfdRv0A0cpSplL+xoZnhG+WE5xBH3uWYd0bS2/ZTQxN1/+BtLgBpRhlOrI54p/c/PUcHGZAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=JjPlKyfHQC7VYkxz3FXMulCTqwAOZk8BKgIBKL9z18NJBKpdffRVb9IHErDj56lIB0Db0RxdmvLK+BnOIrAj2vTNCjVfMF4tCYX3fr+oU5dB5CVFUMnkBjnJmpYbbRf3Qv4XblYl/9uvmml3ID6D7FfHn0BlfaGdo15sUde7czs= Received: by 10.86.99.9 with SMTP id w9mr15918812fgb.44.1199386666795; Thu, 03 Jan 2008 10:57:46 -0800 (PST) Received: by 10.86.62.3 with HTTP; Thu, 3 Jan 2008 10:57:46 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 01:57:46 +0700 From: "Jati Kalingga Praja" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sip] SIP2Megaco Busy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0161668270==" Errors-To: sip-bounces@ietf.org --===============0161668270== Content-Type: multipart/alternative; boundary="----=_Part_12857_17200001.1199386666802" ------=_Part_12857_17200001.1199386666802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,, I'm new to this mailing list. Right now, i'm studying about interworking between megaco and sip. I simulated a call from SIP phone to Analog phone which was busy. You can download the captured data using ethereal in here: http://www.4shared.com/file/33781721/3b2ac786/4577020ke4580220busy.html, and you can view the callflow by writing "*(megaco and ip.addr==10.14.32.186) or (sip and ip.addr==10.14.32.185) or rtp*" in filter textbox. I have a few questions about that captured data : 1. Why did SIP Phone send a CANCEL twice? 2. What did line 2115 mean? I hope my questions are all clear to be understood,,,because i'm not too good in english. Hopefully, you guys can help me. Regards, Jati ------=_Part_12857_17200001.1199386666802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,,

I'm new to this mailing list. Right now, i'm studying about interworking between megaco and sip.
I simulated a call from SIP phone to Analog phone which was busy. You can download the captured data using ethereal in here: http://www.4shared.com/file/33781721/3b2ac786/4577020ke4580220busy.html , and you can view the callflow by writing "(megaco and ip.addr==10.14.32.186) or (sip and ip.addr==10.14.32.185) or rtp" in filter textbox.

I have a few questions about that captured data :
1. Why did SIP Phone send a CANCEL twice?
2. What did line 2115 mean?

I hope my questions are all clear to be understood,,,because i'm not too good in english.
Hopefully, you guys can help me.

Regards,

Jati ------=_Part_12857_17200001.1199386666802-- --===============0161668270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0161668270==-- From sip-bounces@ietf.org Thu Jan 03 14:00:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVIA-0002hP-My; Thu, 03 Jan 2008 13:59:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAVI8-0002h7-Mw for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 13:59:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVI8-0002gN-Az for sip@ietf.org; Thu, 03 Jan 2008 13:59:44 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAVI7-0006K5-Rd for sip@ietf.org; Thu, 03 Jan 2008 13:59:44 -0500 Received: by fg-out-1718.google.com with SMTP id 16so3398611fgg.41 for ; Thu, 03 Jan 2008 10:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=653pRh/daCSnkB9McO4Xmkz9yP/ZwIA9/qYZKlI298Q=; b=a7Cg4cx/Vst9CtyrdQQgcm1ZufaWYOSKVvkDB/qcOcXQkqzL81Qlj7Ew3+m42WrTsbMiOUovNJxFzTAyKwqmb8Bgyuux48OJ/TtGEyjNkCMyLRTQHcJTMdatov3u9IwLR8Go5aQBNWmnIvS7BGjXo689hnJZMjEojZ+4uJ3kKm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=PkUMFNXXm4hNDHvyRli9OQEsqRuGQmPe/m1yCg8IbwO1Y0dVlyZOcG7gYne/hgN1gU+RTzGH6UvmUo4ontAm8YIr0GSjHf4Akd+4euCCtgV0FOKQ3ZlXJLhymCRsmT1D1SPJEX2f+Gto+G9y4Jiw2Ks7+FUqyOrsdqSGD1pK6fI= Received: by 10.86.71.1 with SMTP id t1mr15905356fga.69.1199386783136; Thu, 03 Jan 2008 10:59:43 -0800 (PST) Received: by 10.86.62.3 with HTTP; Thu, 3 Jan 2008 10:59:43 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 01:59:43 +0700 From: "Jati Kalingga Praja" To: megaco@ietf.org, sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Sip] SIP2Megaco Case:Callee onhook first X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809516649==" Errors-To: sip-bounces@ietf.org --===============1809516649== Content-Type: multipart/alternative; boundary="----=_Part_12866_9118058.1199386783128" ------=_Part_12866_9118058.1199386783128 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,, Now, i have questions too in a call from SIP phone to analog phone which the case was the callee onhooked first, which is the analog phone. You can download captured data in this url: http://www.4shared.com/file/33781592/42539b99/4577020ke4580220ttupdtlpn.html. And you can view the data using this filter : *(megaco and ip.addr==10.14.32.186) or (sip and ip.addr==10.14.32.185) or rtp. *The questions are: 1. When the callee onhooked, why did the MGC send INVITE to the SIP Phone (line 3845)? 2. Is that true, that the ring back tone, busy tone, dial tone can be sent using RTP? I mean, why did after 180 Ringing (line 1621), RTP was sent between 10.14.32.185 and 10.14.32.186? Did the RTP contain ring tone?If yes, is there a standard explain this? That's all that i want to ask,,,I hope you guys can help me. Thx in advance before. Regards, Jati ------=_Part_12866_9118058.1199386783128 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,,

Now, i have questions too in a call from SIP phone to analog phone which the case was the callee onhooked first, which is the analog phone. You can download captured data in this url: http://www.4shared.com/file/33781592/42539b99/4577020ke4580220ttupdtlpn.html .  And you can view the data using this filter : (megaco and ip.addr==10.14.32.186) or (sip and ip.addr==10.14.32.185) or rtp.

The questions are:
1. When the callee onhooked, why did the MGC send INVITE to the SIP Phone (line 3845)?
2. Is that true, that the ring back tone, busy tone, dial tone can be sent using RTP? I mean, why did after 180 Ringing (line 1621), RTP was sent between 10.14.32.185 and 10.14.32.186? Did the RTP contain ring tone?If yes, is there a standard explain this?

That's all that i want to ask,,,I hope you guys can help me.
Thx in advance before.

Regards,

Jati ------=_Part_12866_9118058.1199386783128-- --===============1809516649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1809516649==-- From sip-bounces@ietf.org Thu Jan 03 14:15:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVWH-0001xm-4y; Thu, 03 Jan 2008 14:14:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAVWF-0001xG-AO for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 14:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVWF-0001x8-0c for sip@ietf.org; Thu, 03 Jan 2008 14:14:19 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAVWE-0005L6-O1 for sip@ietf.org; Thu, 03 Jan 2008 14:14:18 -0500 Received: by fg-out-1718.google.com with SMTP id 16so3400473fgg.41 for ; Thu, 03 Jan 2008 11:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=G1myiBU3debvF77fNADkU4IHql9G3pojwNxmAyeF6r0=; b=a/uOHXl/MQmzLI5Mi0/H2x3Zhx/VnsxkRVpZTOpRatMZc+bAV4qRwqLrOcAuh4f4v8S/eX092VHw/4GI1Q+0kcYQtODw9mgkdU5QH482qiRNHTju5s323EFXz0VvGW/fWruUKi/J5rQ5pptEF5+VUuhqR+39QZgvFuqGNuQgQCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=jsJSFxU6NQPoKpsEYH+I3O3H2X/LS1dVYn2/zLt4K9eDh1Exim0taKkFD9PjMY6rgkjb4gFo+aPzyQ9fPx5rOPtAFXYJMrgq7449uUXWbYduas9phh9SGi4PIboZITc6FdS3/VPJ4GTcmopD1avdZBAZxgq04noRM70CHZ6j4ck= Received: by 10.86.76.16 with SMTP id y16mr15921287fga.71.1199387657833; Thu, 03 Jan 2008 11:14:17 -0800 (PST) Received: by 10.86.62.3 with HTTP; Thu, 3 Jan 2008 11:14:17 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 02:14:17 +0700 From: "Jati Kalingga Praja" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] SIP2Megaco Busy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1443313885==" Errors-To: sip-bounces@ietf.org --===============1443313885== Content-Type: multipart/alternative; boundary="----=_Part_12896_13154835.1199387657827" ------=_Part_12896_13154835.1199387657827 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is the right url: http://www.4shared.com/account/file/33781721/3b2ac786/4577020ke4580220busy.html?sId=x8tjOAyXOEYhJmc5 . Thx b4... ------=_Part_12896_13154835.1199387657827 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is the right url: http://www.4shared.com/account/file/33781721/3b2ac786/4577020ke4580220busy.html?sId=x8tjOAyXOEYhJmc5 .

Thx b4... ------=_Part_12896_13154835.1199387657827-- --===============1443313885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1443313885==-- From sip-bounces@ietf.org Thu Jan 03 14:16:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVXR-000389-Sx; Thu, 03 Jan 2008 14:15:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAVXQ-00035n-KJ for sip-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 14:15:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVXQ-00035T-93 for sip@ietf.org; Thu, 03 Jan 2008 14:15:32 -0500 Received: from fg-out-1718.google.com ([72.14.220.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAVXP-0006iJ-TV for sip@ietf.org; Thu, 03 Jan 2008 14:15:32 -0500 Received: by fg-out-1718.google.com with SMTP id 16so3400637fgg.41 for ; Thu, 03 Jan 2008 11:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=zk7Q61n+vVrcA9fn0sHmkgL+dHfFKbG5nxoURKy+9P0=; b=F7XIMGPrTvE4pDMEc9DxFJIx7QXd7AssGelMVEHl+pBb9Findgb+VihABJF3cIwv+4PMZKnK4BfYyBJQDtXAMsMh3madI/PsAQAu3ANl7TVVbUHaUrkVl1NteSgx0UxdvixNRgWChBSaiuspOuUCGlTq+6kNpJi3Ln8ARri33Zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=D1K5dASEN9QggykLGy82oy7Kk2q1qTEmm5T8SuHL3JmfAqioJco4K58HVtcY3b2HmMV8zsLqVzRbdBhz1baIIsxh/PQLe9Ck2wHH646BFjvcz5lTpV22Z6Jh3Y5Ck8/1UrbAIuh/a7jmwYM19/4wG9+iKC33aPWcNo7Lhu+0A4M= Received: by 10.86.100.7 with SMTP id x7mr15916364fgb.78.1199387731120; Thu, 03 Jan 2008 11:15:31 -0800 (PST) Received: by 10.86.62.3 with HTTP; Thu, 3 Jan 2008 11:15:31 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 02:15:31 +0700 From: "Jati Kalingga Praja" To: megaco@ietf.org, sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Sip] SIP2Megaco Case:Callee onhook first X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629385480==" Errors-To: sip-bounces@ietf.org --===============1629385480== Content-Type: multipart/alternative; boundary="----=_Part_12898_22803766.1199387731101" ------=_Part_12898_22803766.1199387731101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is the right url: http://www.4shared.com/account/file/33781592/42539b99/4577020ke4580220ttupdtlpn.html?sId=x8tjOAyXOEYhJmc5 Thx b4... ------=_Part_12898_22803766.1199387731101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is the right url: http://www.4shared.com/account/file/33781592/42539b99/4577020ke4580220ttupdtlpn.html?sId=x8tjOAyXOEYhJmc5

Thx b4... ------=_Part_12898_22803766.1199387731101-- --===============1629385480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1629385480==-- From sip-bounces@ietf.org Fri Jan 04 09:43:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAnlC-0004Gq-Aa; Fri, 04 Jan 2008 09:42:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAnYG-00058R-6A for sip-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 09:29:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAnYF-00058I-SV; Fri, 04 Jan 2008 09:29:35 -0500 Received: from exchange.txpcorporation.com ([207.71.49.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAnYF-0004Ap-AH; Fri, 04 Jan 2008 09:29:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Jan 2008 08:29:34 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] SIP2Megaco Case:Callee onhook first Thread-Index: AchOhqwAvMB/tVfDRdS0O1DrjfN5CAAVrxog References: From: "John Wainwright" To: "Jati Kalingga Praja" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae X-Mailman-Approved-At: Fri, 04 Jan 2008 09:42:56 -0500 Cc: Subject: [Sip] RE: [Megaco] SIP2Megaco Case:Callee onhook first X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1238434013==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1238434013== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84EDE.3A632A99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84EDE.3A632A99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tones can be played over the RTP stream. Typically a tone is defined as proceeding from the Termination towards the exterior of the context so if a tone is requested to be played on a Phy termination it is played/generated locally while if it is played to the EPH termination it is played on the RTP stream. =20 See megaco standards document section 7.1.11 ( V2 document ) =20 John =20 =20 ________________________________ From: Jati Kalingga Praja [mailto:king.of.kalingga@gmail.com]=20 Sent: Thursday, January 03, 2008 12:25 PM To: megaco@ietf.org; sip@ietf.org Subject: [Megaco] SIP2Megaco Case:Callee onhook first =20 Hi,, Now, i have questions too in a call from SIP phone to analog phone which the case was the callee onhooked first, which is the analog phone. Here, i attached captured data too. You can view the data using this filter : (megaco and ip.addr=3D=3D10.14.32.186) or (sip and = ip.addr=3D=3D10.14.32.185) or rtp. The questions are: 1. When the callee onhooked, why did the MGC send INVITE to the SIP Phone (line 3845)? 2. Is that true, that the ring back tone, busy tone, dial tone can be sent using RTP? I mean, why did after 180 Ringing (line 1621), RTP was sent between 10.14.32.185 and 10.14.32.186? Did the RTP contain ring tone?If yes, is there a standard explain this? That's all that i want to ask,,,I hope you guys can help me.=20 Thx in advance before. Regards, Jati ------_=_NextPart_001_01C84EDE.3A632A99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tones can be played over the RTP stream.  Typically a tone is defined as proceeding from the = Termination towards the exterior of the context so if a tone is requested to be = played on a Phy termination it is played/generated locally while if it is played to = the EPH termination it is played on the RTP stream.

 

See megaco standards document = section 7.1.11 ( V2 document )

 

John

 

 

From: Jati = Kalingga Praja [mailto:king.of.kalingga@gmail.com]
Sent: Thursday, January = 03, 2008 12:25 PM
To: megaco@ietf.org; = sip@ietf.org
Subject: [Megaco] = SIP2Megaco Case:Callee onhook first

 

Hi,,

Now, i have questions too in a call from SIP phone to analog phone which = the case was the callee onhooked first, which is the analog phone. Here, i = attached captured data too. You can view the data using this filter : (megaco and ip.addr=3D=3D10.14.32.186) or = (sip and ip.addr=3D=3D10.14.32.185) or rtp.

The questions are:
1. When the callee onhooked, why did the MGC send INVITE to the SIP = Phone (line 3845)?
2. Is that true, that the ring back tone, busy tone, dial tone can be = sent using RTP? I mean, why did after 180 Ringing (line 1621), RTP was sent = between 10.14.32.185 and 10.14.32.186? Did the RTP contain ring tone?If yes, is there a standard explain = this?

That's all that i want to ask,,,I hope you guys can help me.
Thx in advance before.

Regards,

Jati

------_=_NextPart_001_01C84EDE.3A632A99-- --===============1238434013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1238434013==-- From sip-bounces@ietf.org Fri Jan 04 11:20:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApGb-0002NL-NY; Fri, 04 Jan 2008 11:19:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JApGa-0002ND-2i for sip-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 11:19:28 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JApGZ-0002N2-PK for sip@ietf.org; Fri, 04 Jan 2008 11:19:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAod8-0001qi-QY for sip@ietf.org; Fri, 04 Jan 2008 10:38:42 -0500 Received: from fg-out-1718.google.com ([72.14.220.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAod7-0001oJ-SI for sip@ietf.org; Fri, 04 Jan 2008 10:38:42 -0500 Received: by fg-out-1718.google.com with SMTP id 16so3598619fgg.41 for ; Fri, 04 Jan 2008 07:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=wxDhDyNFWBuAlCg9PxloWtFp97O9oZy8Sv1GP0ifAOc=; b=X9CiCZSCqvdtBSml21h1KIC7Ie0i7++gfy1NaQzE600Kji8SMGNzYH72O+RdZFX7g7KaRLdRmcFu170vn4oLR8N5C034bRVQjRJFg24eiNaECZpGk20c3qvEQ4HHsT18xgDzk7OMVI/Fyz+MzjlV4VCIaHOY3SR2rf1z7ZgML/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=Xw0p95BVjJzQMvaLVyfXKcAloUsA/OjNjR5CGuSKgGXpIPKgFnWmD8jCHxEOF2ntHIxbJ3UsrSaqzCW8EheTgcnWyTyNXyOONOh/eXvRW5bbjX+AIFBzWNwQgIRCiEXoJu8C3QtzFH+uBnC0jJbkiW0PxBeZR4aS8JvXMmLnkR4= Received: by 10.86.53.8 with SMTP id b8mr8136275fga.64.1199461121176; Fri, 04 Jan 2008 07:38:41 -0800 (PST) Received: by 10.86.89.20 with HTTP; Fri, 4 Jan 2008 07:38:41 -0800 (PST) Message-ID: <14b80930801040738r69009873kec9385762a3c9d2a@mail.gmail.com> Date: Fri, 4 Jan 2008 21:08:41 +0530 From: "Hulbut hulbut" To: rohan@ekabal.com Subject: [Sip] Few Doubts/comments in draft-ietf-sip-outbound-11 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-TMDA-Confirmed: Fri, 04 Jan 2008 11:19:27 -0500 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0754049537==" Errors-To: sip-bounces@ietf.org --===============0754049537== Content-Type: multipart/alternative; boundary="----=_Part_8452_1707479.1199461121169" ------=_Part_8452_1707479.1199461121169 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Rohan, I have following doubts in draft: 1) There is a typo (I think) in section 5.3 If the flow in the flow token in the topmost Route header field value matches the source of the request, the request *in* an "outgoing" request. For an "outgoing" request, the edge proxy just removes the Route header and continues processing the request. Otherwise, this is an "incoming" request. Instead of "in" there should be "is" 2) Section 5.3(Forwarding Non-Register requests), evaluates inbound/outbound on the basis of Flow token. If the flow in the flow token in the topmost Route header field value matches the source of the request, the request in an "outgoing" request. For an "outgoing" request, the edge proxy just removes the Route header and continues processing the request. Otherwise, this is an "incoming" request. However in the mentioned decode algorithm, above mismatch will lead to sending 403 forbidden. Example Algorithm: To decode the flow token, take the flow identifier in the user portion of the URI and base64 decode it, then verify the HMAC is correct by recomputing the HMAC and checking that it matches. If the HMAC is not correct, the proxy SHOULD send a 403 (Forbidden) response. If the HMAC is correct then the proxy SHOULD forward the request on the flow that was specified by the information in the flow identifier. If this flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request. I think inbound/outbound determination can be left to the proxy's own implementation. Regarding sending 403 response when HMAC mismatch happens, I am not clear how will any request be sent to UEs Considering an Edge proxy receives request from some other server (authoritative server), the flow token in route header would be pointing to UEs source address(or NAT mapped address) but the value which Edge proxy will compute will be based on the source address of other server. Thus, in case of inbound all requests will be rejected by 403 . Please correct me ! Thanks Hulbut ------=_Part_8452_1707479.1199461121169 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi Rohan,

I have following doubts in draft:

1) There is a typo (I think) in section 5.3 

   If the flow in the flow token in the topmost Route header field value
   matches the source of the request, the request 
in an "outgoing" 
   request.  For an "outgoing" request, the edge proxy just removes the
   Route header and continues processing the request.
  Otherwise, this
   is an "incoming" request. 
 Instead of "in" there should be "is"

2) Section 5.3(Forwarding Non-Register requests), evaluates inbound/outbound on the basis of Flow token. 

   If the flow in the flow token in the topmost Route header field value
   matches the source of the request, the request in an "outgoing"

   request.  For an "outgoing" request, the edge proxy just removes the
   Route header and continues processing the request.
  Otherwise, this
   is an "incoming" request. 

However in the mentioned decode algorithm, above mismatch will lead to sending 403 forbidden.

   Example Algorithm:  To decode the flow token, take the flow
      identifier in the user portion of the URI and base64 decode it,
      then verify the HMAC is correct by recomputing the HMAC and
      checking that it matches.  If the HMAC is not correct, the proxy
      SHOULD send a 403 (Forbidden) response.  If the HMAC is correct
      then the proxy SHOULD forward the request on the flow that was
      specified by the information in the flow identifier.  If this flow
      no longer exists, the proxy SHOULD send a 430 (Flow Failed)
      response to the request.


I think inbound/outbound determination can be left to the proxy's own implementation.
Regarding sending 403 response when HMAC mismatch happens, I am not clear how will any request be sent to UEs
Considering an Edge proxy receives request from some other server (authoritative server), the flow token in route header would be
pointing to UEs source address(or NAT mapped address) but the value which Edge proxy will compute will be based on the source address of other server.
Thus, in case of inbound all requests will be rejected by 403 .


Please correct me !

Thanks
Hulbut

 


------=_Part_8452_1707479.1199461121169-- --===============0754049537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0754049537==-- From sip-bounces@ietf.org Sat Jan 05 02:48:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB3lN-00087q-5r; Sat, 05 Jan 2008 02:48:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JB3lL-00087k-Jh for sip-confirm+ok@megatron.ietf.org; Sat, 05 Jan 2008 02:48:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB3lH-0007rj-MX for sip@ietf.org; Sat, 05 Jan 2008 02:48:07 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JB3lH-0007H5-9n for sip@ietf.org; Sat, 05 Jan 2008 02:48:07 -0500 Received: by fg-out-1718.google.com with SMTP id 16so3749215fgg.41 for ; Fri, 04 Jan 2008 23:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=/EZDp3lJa/8+hlS4XghGeptYXrvMQF+H4Vqw0iVWQYU=; b=reA7D2+wzS8+bKB/RpxGZmfXT9ChqUDQqI6FbMUbfSJp5ipVL+JanZVyvo7sdEjIHY/h1KDk6v0/Kq+3eQjmxxvF7UuKlCkedz1M8tia9yGQJQRijl5sbYhbwfOvTKF6Gu4R1evMdhTqSjgvCsojY91xthlKflSX7KDHB+yccj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=NSFijTyeRW0HTBmMseF3X+AIOj0IfTJ+Ldj9zZ9p8CvUJuYGcLG2Y6U9+ETVh3Z7Nf4RIHpKiN2k1gG/+nkYsT68N0kIRyx7onUuLIF1SSHCMXlcV8CX1bWvmrgBte1sBFl2fatRVSLHfV2EijoSFBmx+Ol8B1N7wdeRZaFYogs= Received: by 10.86.84.5 with SMTP id h5mr17635184fgb.53.1199519285974; Fri, 04 Jan 2008 23:48:05 -0800 (PST) Received: by 10.86.61.5 with HTTP; Fri, 4 Jan 2008 23:48:05 -0800 (PST) Message-ID: Date: Sat, 5 Jan 2008 14:48:05 +0700 From: "Jati Kalingga Praja" To: sip@ietf.org, megaco@ietf.org, sip-implementors@lists.cs.columbia.edu MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Sip] Delay Translation Definition And Message Mapping,, X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2094780219==" Errors-To: sip-bounces@ietf.org --===============2094780219== Content-Type: multipart/alternative; boundary="----=_Part_7465_10164989.1199519285981" ------=_Part_7465_10164989.1199519285981 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,,, Right now i'm studying interworking between megaco and sip. Is there any exact definition about delay translation?And is there any specs about delay translation in this interworking? And how about the message mapping? I'm confused in counting the delay translation value. For example, if the caller is using sip, MG will send only INVITE to MGC,,it is different if the caller is analog phone, MG will send a lot of Megaco message to MGC (Notify Offhook, Modify, Notify digits, Add),,how can i count the delay translation here? Hopefully you guys can help me,, Regards, Jati ------=_Part_7465_10164989.1199519285981 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,,,

Right now i'm studying interworking between megaco and sip. Is there any exact definition about delay translation?And is there any specs about delay translation in this interworking? And how about the message mapping?
I'm confused in counting the delay translation value. For example, if the caller is using sip, MG will send only INVITE to MGC,,it is different if the caller is analog phone, MG will send a lot of Megaco message to MGC (Notify Offhook, Modify, Notify digits, Add),,how can i count the delay translation here?

Hopefully you guys can help me,,

Regards,

Jati
------=_Part_7465_10164989.1199519285981-- --===============2094780219== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2094780219==-- From sip-bounces@ietf.org Sun Jan 06 20:52:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBh97-00067j-0L; Sun, 06 Jan 2008 20:51:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JBh95-00067Y-Pw for sip-confirm+ok@megatron.ietf.org; Sun, 06 Jan 2008 20:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBh95-00067Q-GH; Sun, 06 Jan 2008 20:51:19 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBh93-0004Dr-R3; Sun, 06 Jan 2008 20:51:19 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m071pEfe017080; Sun, 6 Jan 2008 19:51:14 -0600 (CST) Received: from cnexp02.bj.lucent.com ([135.252.8.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jan 2008 19:51:13 -0600 Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.27]) by cnexp02.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:51:11 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] SIP2Megaco Case:Callee onhook first Date: Mon, 7 Jan 2008 09:50:25 +0800 Message-ID: <1F053F0D5C42184B9878C8D79BAE7D16295765@CNEXC1U03.BJ.LUCENT.COM> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP2Megaco Case:Callee onhook first Thread-Index: AchOOtUYpUYWbH0oQViWqYn2hAtR5wClJZeQ From: "Zhang, Rocky Fan Wen \(Rocky\)" To: "Jati Kalingga Praja" , , X-OriginalArrivalTime: 07 Jan 2008 01:51:11.0195 (UTC) FILETIME=[C748D2B0:01C850CF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.9 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1464347566==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1464347566== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C850CF.C6ED2033" This is a multi-part message in MIME format. ------_=_NextPart_001_01C850CF.C6ED2033 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 About your second question, you can find help from RFC 3959 and RFC 3960 which tells early media. Yes, after 180 there can follows RTP packets to let the endpoint to play remote media. =20 =20 =20 Best Regards, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fanwen zhang FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D Tel: +86-532-88615493 Email:fanwenz@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ________________________________ From: Jati Kalingga Praja [mailto:king.of.kalingga@gmail.com]=20 Sent: Friday, January 04, 2008 3:00 AM To: megaco@ietf.org; sip@ietf.org Subject: [Sip] SIP2Megaco Case:Callee onhook first Hi,, Now, i have questions too in a call from SIP phone to analog phone which the case was the callee onhooked first, which is the analog phone. You can download captured data in this url: http://www.4shared.com/file/33781592/42539b99/4577020ke4580220ttupdtlpn. html . And you can view the data using this filter : (megaco and ip.addr=3D=3D10.14.32.186) or (sip and ip.addr=3D=3D10.14.32.185) or = rtp. The questions are: 1. When the callee onhooked, why did the MGC send INVITE to the SIP Phone (line 3845)?=20 2. Is that true, that the ring back tone, busy tone, dial tone can be sent using RTP? I mean, why did after 180 Ringing (line 1621), RTP was sent between 10.14.32.185 and 10.14.32.186 ? Did the RTP contain ring tone?If yes, is there a standard explain this? That's all that i want to ask,,,I hope you guys can help me.=20 Thx in advance before. Regards, Jati=20 ------_=_NextPart_001_01C850CF.C6ED2033 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
About your second question, you can find help = from RFC 3959=20 and RFC 3960 which tells early media.
Yes, after 180 there can follows RTP packets to = let the=20 endpoint to play remote media.
 
 
 
Best Regards,
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fanwen zhang
FS5000 CPE IOT, Alcatel-Lucent = Qingdao,=20 R&D
Tel:=20 +86-532-88615493
Email:fanwenz@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 

From: Jati Kalingga Praja=20 [mailto:king.of.kalingga@gmail.com]
Sent: Friday, January 04, = 2008=20 3:00 AM
To: megaco@ietf.org; sip@ietf.org
Subject: = [Sip]=20 SIP2Megaco Case:Callee onhook first

Hi,,

Now, i have questions too in a call from SIP = phone to=20 analog phone which the case was the callee onhooked first, which is the = analog=20 phone. You can download captured data in this url: http://www.4shared.com/file/33781592/42539b99/4577020ke45802= 20ttupdtlpn.html=20 .  And you can view the data using this filter : (megaco and = ip.addr=3D=3D10.14.32.186) or (sip and ip.addr=3D=3D10.14.32.185) or = rtp.

The=20 questions are:
1. When the callee onhooked, why did the MGC send = INVITE to=20 the SIP Phone (line 3845)?
2. Is that true, that the ring back tone, = busy=20 tone, dial tone can be sent using RTP? I mean, why did after 180 Ringing = (line=20 1621), RTP was sent between 10.14.32.185 and 10.14.32.186? Did the RTP contain ring tone?If yes, = is there a=20 standard explain this?

That's all that i want to ask,,,I hope you = guys=20 can help me.
Thx in advance before.

Regards,

Jati ------_=_NextPart_001_01C850CF.C6ED2033-- --===============1464347566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1464347566==-- From sip-bounces@ietf.org Sun Jan 06 22:20:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBiWQ-0002wv-On; Sun, 06 Jan 2008 22:19:30 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JBiWP-0002pP-7J for sip-confirm+ok@megatron.ietf.org; Sun, 06 Jan 2008 22:19:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBiWO-0002lH-RN for sip@ietf.org; Sun, 06 Jan 2008 22:19:28 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBiWN-0003fT-V0 for sip@ietf.org; Sun, 06 Jan 2008 22:19:28 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m073JCWe026751; Sun, 6 Jan 2008 21:19:15 -0600 (CST) Received: from cnexp01.bj.lucent.com ([135.252.8.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jan 2008 21:19:13 -0600 Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.27]) by cnexp01.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 11:19:09 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] INVITE after terminated dialog? Date: Mon, 7 Jan 2008 11:18:23 +0800 Message-ID: <1F053F0D5C42184B9878C8D79BAE7D1629579D@CNEXC1U03.BJ.LUCENT.COM> In-Reply-To: <200801030316.m033GiGC020872@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INVITE after terminated dialog? Thread-Index: AchNtyoNAqifhia0RDm7lmEQIqiHdgDHzFBQ From: "Zhang, Rocky Fan Wen \(Rocky\)" To: , X-OriginalArrivalTime: 07 Jan 2008 03:19:09.0125 (UTC) FILETIME=[112D0750:01C850DC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 It seems you have used TISPAN mode. I think the reasonable process should be: - When flashes at endpoint it will send out a INVITE but it is not a re-INVITE. - When AS receive this INVITE it should return 200 OK - The endpoint return a ACK, and the second INVITE is ignored and the announcement goes on. =20 =20 Best Regards, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fanwen zhang FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D Tel: +86-532-88615493 Email:fanwenz@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Thursday, January 03, 2008 11:17 AM To: sip@ietf.org Subject: Re: [Sip] INVITE after terminated dialog? From: "Jane Jiang" Hi All, There is a weird situation with us: (1) A Linksys phone sends an INVITE out with incorrect destination TN. As a result, our application server will set up a call between the Linksys phone and an IVR (2) A user incorrectly hits the on-hold key, which is basically sending a re-INVITE to the IVR (3) Our server seems to have answered the re-INVITE with a BYE (4) The Linksys phone responds to the BYE with a 200 (5) Afterwards, the Linksys phone still thinks that its original re-INVITE has not been responded. So, it will keep resend re-INVITE The consequence of these re-INVITEs is a registration migration, which we don't like. We have been trying to figure out which side is not following RFC 3261, the phone, the SBCs are wrong, or the application servers. I am wondering: (A) Is it legal for a server to ignore the re-INVITE and respond with a BYE and has nothing in between? The server can legally send a request before responding to a request it has received. Indeed, it must be allowed to do so, as from the protocol point of view that action is indistinguishable from the network delaying the re-INVITE. However, the server remains obliged to send a response to the re-INVITE, as each request is a separate transaction that demands a response. In this case, 481 Dialog Usage Does Not Exist seems most appropriate. (B) If a UA has responded to a BYE with 200, is it supposed to forget about the re-INVITE request that it has sent out and not try to resend the re-INVITE, assuming a dialog has already been terminated with the BYE/200 transaction? In principle, the re-INVITE is a separate transaction and the UA should complete processing that transaction by re-sending to get a response (until the time-out). However, the server cannot enforce that (as it is possible that the network has lost all sends of the request), and if the UA decides that it no longer is concerned with the response the re-INVITE might get, it can give up resending the re-INVITE. Maybe in another sentence, is it legal to send our re-INVITEs outside an dialog, even if these re-INVITEs are the repeats of an original in-dialog re-INVITE? A re-INVITE is by definition within a dialog, since a re-INVITE is (by definition) an INVITE with a to-tag. However, if the INVITE dialog usage of the dialog has been terminated (by the server sending the BYE), the re-INVITE will fail, as you can't create a new INVITE dialog usage within a dialog that has had one which has been terminated. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 07 07:03:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBqgR-0008GG-NS; Mon, 07 Jan 2008 07:02:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JBqgP-0008FR-NC for sip-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 07:02:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBqgP-0008F3-C9 for sip@ietf.org; Mon, 07 Jan 2008 07:02:21 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBqgO-0004ZH-J1 for sip@ietf.org; Mon, 07 Jan 2008 07:02:21 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id m07C2JNI079972 for ; Mon, 7 Jan 2008 12:02:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m07C2IIL2121886 for ; Mon, 7 Jan 2008 13:02:18 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m07C2IkE011549 for ; Mon, 7 Jan 2008 13:02:18 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m07C2I1a011535; Mon, 7 Jan 2008 13:02:18 +0100 To: sip@ietf.org, jari.urpalainen@nokia.com MIME-Version: 1.0 X-KeepSent: E149880F:A529696C-C22573C9:00416690; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Mon, 7 Jan 2008 14:02:17 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0|August 02, 2007) at 07/01/2008 14:02:17, Serialize complete at 07/01/2008 14:02:17 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: [Sip] draft-ietf-sip-xcapevent-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1258268591==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1258268591== Content-Type: multipart/alternative; boundary="=_alternative 00422567C22573C9_=" This is a multipart message in MIME format. --=_alternative 00422567C22573C9_= Content-Type: text/plain; charset="US-ASCII" Wish to get a clarification regarding what will happen when we subscribe to the resources below and the first entry does not exist while the other two do exist. Assume that we get a pending notification, when and how will it be possible to know which resource does exist and which one does not. What will be the content of the pending notification and how it will be possible to know which one exist? --Avshalom --=_alternative 00422567C22573C9_= Content-Type: text/html; charset="US-ASCII"
Wish to get a clarification regarding what will happen when we subscribe to the
resources below and the first entry does not exist while the other two do exist.
Assume that we get a pending notification, when and how will it be possible to
know which resource does exist and which one does not.

What will be the content of the pending notification and how it will be possible
to know which one exist?


   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
    <list>
     <entry uri="resource-lists/users/sip:joe@example.com/index"/>
     <entry uri="rls-services/users/sip:joe@example.com/index/
   ~~/*/service%5b@uri='sip:marketing@example.com'%5d"/>
     <entry uri="pidf-manipulation/"/>
    </list>
   </resource-lists>
--Avshalom

 --=_alternative 00422567C22573C9_=-- --===============1258268591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1258268591==-- From sip-bounces@ietf.org Mon Jan 07 09:40:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBt8e-0004gp-R8; Mon, 07 Jan 2008 09:39:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JBt8b-0004gh-V1 for sip-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 09:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBt8b-0004gZ-LM for Sip@ietf.org; Mon, 07 Jan 2008 09:39:37 -0500 Received: from fk-out-0910.google.com ([209.85.128.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBt8Z-00078g-FX for Sip@ietf.org; Mon, 07 Jan 2008 09:39:37 -0500 Received: by fk-out-0910.google.com with SMTP id z23so8546238fkz.5 for ; Mon, 07 Jan 2008 06:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=sJ3XDgJyjgm+XL6yZELnhQK3X+DIi29H6bj1mjk8wUQ=; b=iYyUp5hYoX7BMFQjYMuwAhPWQOxkl1mq8rzUmdVuRoymZiLQ8IcYdUWYOT5hQnDKXTLwosuySKHgoUNfZOldcCzZd2BQtFT1Z82zy1aWzlCIR4XoRetOT19CR5QvwNXZEDLEpcDPUFM9soqI0OsYFEY7EOez/S5WKq8CQXjdfPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Bj7g9LcXaqAQyO85DXVPwkM/+mqpwALO0uOWbkKeoXWZFnc+yBuRi6O4JU9GBYCKcG0DUki5iRwnv8s0Svo7wNuNtjki1fa/JoOZvmeGxyorD0+UyhCpvFgnstuGkBdDbBvPF9MvXv83mx8eYWbekI97XD8xlfknmtdce35miIk= Received: by 10.82.174.20 with SMTP id w20mr35480517bue.28.1199716774160; Mon, 07 Jan 2008 06:39:34 -0800 (PST) Received: by 10.82.162.15 with HTTP; Mon, 7 Jan 2008 06:39:34 -0800 (PST) Message-ID: Date: Mon, 7 Jan 2008 15:39:34 +0100 From: "Karl Heinz Wolf" To: Sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Sip] Re: SIP Location Conveyance revved (-09) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org by James M. Polk Nov 21, 2007; 09:56pm < - made "inserted-by=" a mandatory header parameter. This is because < there is a comparable header for errors that needs this parameter's < value. I'll mention that in a bit. Hi James, I just had a look at the draft because of the "inserted-by" parameter and noticed the following inconsistency: Section 3 says: The Geolocation header can have parameters that are associated with a URI in the header field. The "inserted-by" parameter has values of "endpoint" or "server", indicating which entry added location to the message. This header parameter MAY be added every time a new location is added into a message. But below it is a "must" and the parameter contains the host name. -karl heinz _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 07 18:43:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1bS-00078P-E2; Mon, 07 Jan 2008 18:41:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JC1bQ-00078J-VU for sip-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 18:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1bQ-00078B-Ls for sip@ietf.org; Mon, 07 Jan 2008 18:41:56 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC1bQ-00037o-Fp for sip@ietf.org; Mon, 07 Jan 2008 18:41:56 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 18:41:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] doubt regarding early session in sip RFC 3959/3960 Date: Mon, 7 Jan 2008 18:41:54 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] doubt regarding early session in sip RFC 3959/3960 Thread-Index: AchLdqxoNNipL/PQQ0yJ5enqwGBudgGCTuMQ From: "Brett Tate" To: , X-OriginalArrivalTime: 07 Jan 2008 23:41:55.0720 (UTC) FILETIME=[E3130080:01C85186] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Gonzalo.Camarillo@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > UAS is expecting " early-answer " in PRACK from=20 > the UAC, what will happen if UAC does not=20 > support "100rel" (RFC 3262).=20 RFC 3959 section 4 indicates that early-session must follow the offer/answer model. Thus an early-session cannot be setup by indicating an offer within 18x when 100rel is not being used. > And RFC 3959 is not mandating the "100rel" extension=20 > at UA for the same. Can anyone give an example of =20 > early session flow in case of UAC is not=20 > supporting "100rel". (UPDATE..?)=20 =09 It is generically discussed within rfc3959 section 4. =20 UPDATE and rfc3311 are not specifically discussed with rfc3959. I'm not sure if this was an oversight or because maybe UPDATE currently defined to "modify" a session instead of "establish" a session. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 08 05:08:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBLY-0002KK-BQ; Tue, 08 Jan 2008 05:06:12 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCBLV-0002KB-Ok for sip-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 05:06:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBLU-0002K1-Mi for sip@ietf.org; Tue, 08 Jan 2008 05:06:08 -0500 Received: from tapal.aricent.com ([59.165.248.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCBLR-0004EZ-Uq for sip@ietf.org; Tue, 08 Jan 2008 05:06:08 -0500 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id m08A5BJX017207 for ; Tue, 8 Jan 2008 15:35:11 +0530 Received: from pragati.bgh.aricent.com (pragati.bgh.aricent.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id m08A5BGF017198for ; Tue, 8 Jan 2008 15:35:11 +0530 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Ranjith.V@aricent.com Date: Tue, 8 Jan 2008 15:33:00 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at01/08/2008 03:32:46 PM,Serialize complete at 01/08/2008 03:32:46 PM X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-11.8939 TC:1F TRN:52 TV:5.0.1023(15654.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.8 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Sip] questions regarding AKAv2 implementation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0556770380==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0556770380== Content-Type: multipart/alternative; boundary="=_alternative 0037BCC1652573CA_=" This is a multipart message in MIME format. --=_alternative 0037BCC1652573CA_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgQWxsLA0KICAgICAgICBXZSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBQUkYgZnVu Y3Rpb24gaW4gQUtBdjIoSUVURiBSRkMgDQo0MTY5KS4gc2VjdGlvbiAyLjEgb2YgdGhlIFJGQyA0 MTY5IHN0YXRlcyB0aGUgZm9sbG93aW5nLi4NCg0KMi4xLiBQYXNzd29yZCBHZW5lcmF0aW9uDQoN ClRoZSBjbGllbnQgc2hhbGwgdXNlIGJhc2U2NCBlbmNvZGVkIFsxXSBwYXJhbWV0ZXJzIFBSRihS RVN8fElLfHxDSywNCiJodHRwLWRpZ2VzdC1ha2F2Mi1wYXNzd29yZCIpIGFzIGEgInBhc3N3b3Jk IiB3aGVuIGNhbGN1bGF0aW5nIHRoZQ0KSFRUUCBEaWdlc3QgcmVzcG9uc2UgZGlyZWN0aXZlIGZv ciBBS0F2Mi4NCg0KaWYgdGhlIGFsZ29yaXRobSBpcyBBS0F2Mi1NRDUsIHRoZW4gdGhlIFBSRiBp cyBITUFDX01ENS4NCg0KUkZDIDIxMDQgZGVmaW5lcyB0aGUgSE1BQ19NRDUgdG8gYmUgdGhlIGZv bGxvd2luZw0KDQovKg0KKiogRnVuY3Rpb246IGhtYWNfbWQ1DQoqLw0Kdm9pZA0KaG1hY19tZDUo dGV4dCwgdGV4dF9sZW4sIGtleSwga2V5X2xlbiwgZGlnZXN0KQ0KdW5zaWduZWQgY2hhciogdGV4 dDsgLyogcG9pbnRlciB0byBkYXRhIHN0cmVhbSAqLw0KaW50IHRleHRfbGVuOyAvKiBsZW5ndGgg b2YgZGF0YSBzdHJlYW0gKi8NCnVuc2lnbmVkIGNoYXIqIGtleTsgLyogcG9pbnRlciB0byBhdXRo ZW50aWNhdGlvbiBrZXkgKi8NCmludCBrZXlfbGVuOyAvKiBsZW5ndGggb2YgYXV0aGVudGljYXRp b24ga2V5ICovDQpjYWRkcl90IGRpZ2VzdDsgLyogY2FsbGVyIGRpZ2VzdCB0byBiZSBmaWxsZWQg aW4gKi8NCg0KT3VyIHF1ZXJ5DQo9PT09PT09PT0NCmhtYWNfbWQ1KCkgZnVuY3Rpb24gdGFrZXMg dGV4dCAsIGtleSBhcyBpbnB1dHMuIEFzIHdlIHVuZGVyc3RhbmQga2V5IA0KY29ycmVzcG9uZHMg dG8gUkVTfHxJS3x8Q0sgYW5kIHRleHQgY29ycmVzcG9uZHMgdG8gDQoiaHR0cC1kaWdlc3QtYWth djItcGFzc3dvcmQiLi4ud2Ugd291bGQgbGlrZSB0byBrbm93IHdoZXRoZXIgb3VyIA0KdW5kZXJz dGFuZGluZyBpcyBjb3JyZWN0Lg0KDQpSYWp1DQogDQogDQoNCioqKioqKioqKioqKioqKioqKioq KioqICBBcmljZW50LVJlc3RyaWN0ZWQgICAqKioqKioqKioqKioqKioqKioqKioqKg0KIkRJU0NM QUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50IGFuZCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMg YWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVy cG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcs IGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1l c3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFt YWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBi eSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 0037BCC1652573CA_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mz5IaSBBbGwsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2UgaGF2ZSBhIHF1ZXN0aW9uIHJl Z2FyZGluZw0KdGhlIFBSRiBmdW5jdGlvbiBpbiA8Yj5BS0F2MjwvYj4oSUVURiBSRkMgNDE2OSku IHNlY3Rpb24gMi4xIG9mIHRoZSBSRkMNCjQxNjkgc3RhdGVzIHRoZSBmb2xsb3dpbmcuLjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Mi4xLiBQYXNzd29yZCBHZW5lcmF0 aW9uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGUgY2xpZW50IHNo YWxsIHVzZSBiYXNlNjQgZW5jb2RlZCBbMV0gcGFyYW1ldGVycw0KUFJGKFJFU3x8SUt8fENLLDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7aHR0cC1kaWdlc3QtYWthdjIt cGFzc3dvcmQmcXVvdDspIGFzIGEgJnF1b3Q7cGFzc3dvcmQmcXVvdDsNCndoZW4gY2FsY3VsYXRp bmcgdGhlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IVFRQIERpZ2VzdCByZXNw b25zZSBkaXJlY3RpdmUgZm9yIEFLQXYyLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+aWYgdGhlIGFsZ29yaXRobSBpcyBBS0F2Mi1NRDUsIHRoZW4gdGhlIFBSRiBpcyBI TUFDX01ENS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxiPlJGQyAy MTA0IGRlZmluZXMgdGhlIEhNQUNfTUQ1IHRvIGJlIHRoZSBmb2xsb3dpbmc8L2I+PC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4vKjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+KiogRnVuY3Rpb246IGhtYWNfbWQ1PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4qLzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dm9pZDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aG1hY19tZDUodGV4dCwgdGV4dF9sZW4sIGtl eSwga2V5X2xlbiwgZGlnZXN0KTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dW5z aWduZWQgY2hhciogdGV4dDsgLyogcG9pbnRlciB0byBkYXRhIHN0cmVhbSAqLzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aW50IHRleHRfbGVuOyAvKiBsZW5ndGggb2YgZGF0YSBz dHJlYW0gKi88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnVuc2lnbmVkIGNoYXIq IGtleTsgLyogcG9pbnRlciB0byBhdXRoZW50aWNhdGlvbiBrZXkNCiovPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5pbnQga2V5X2xlbjsgLyogbGVuZ3RoIG9mIGF1dGhlbnRpY2F0 aW9uIGtleSAqLzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Y2FkZHJfdCBkaWdl c3Q7IC8qIGNhbGxlciBkaWdlc3QgdG8gYmUgZmlsbGVkIGluICovPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mz48Yj5PdXIgcXVlcnk8L2I+PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mz48Yj49PT09PT09PT08L2I+PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mz5obWFjX21kNSgpIGZ1bmN0aW9uIHRha2VzIHRleHQgLCBrZXkgYXMgaW5wdXRz LiBBcw0Kd2UgdW5kZXJzdGFuZCA8Yj5rZXk8L2I+IGNvcnJlc3BvbmRzIHRvIDxiPlJFU3x8SUt8 fENLPC9iPiBhbmQgPGI+dGV4dDwvYj4NCmNvcnJlc3BvbmRzIHRvIDxiPiZxdW90O2h0dHAtZGln ZXN0LWFrYXYyLXBhc3N3b3JkJnF1b3Q7PC9iPi4uLndlIHdvdWxkDQpsaWtlIHRvIGtub3cgd2hl dGhlciBvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LjwvZm9udD48L3R0Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpSYWp1PGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioq KiogJm5ic3A7QXJpY2VudC1SZXN0cmljdGVkICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioq KjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAw MDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmlj ZW50IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFs IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1 c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJp dGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250 ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBm b3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4i CjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 0037BCC1652573CA_=-- --===============0556770380== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0556770380==-- From sip-bounces@ietf.org Tue Jan 08 10:31:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGPI-0008NT-L7; Tue, 08 Jan 2008 10:30:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCGPG-0008M8-Mr for sip-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 10:30:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGPG-00086H-An; Tue, 08 Jan 2008 10:30:22 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCGPA-00069U-IU; Tue, 08 Jan 2008 10:30:17 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m08FTwDM018178; Tue, 8 Jan 2008 09:29:58 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m08FTqj02018; Tue, 8 Jan 2008 09:29:59 -0600 (CST) Message-ID: <478396EF.3090502@alcatel-lucent.com> Date: Tue, 08 Jan 2008 09:29:51 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dburnett@voxeo.com, sarvi@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 1.5 (+) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: IETF SIP List , speechsc@ietf.org, speechsc-chairs@tools.ietf.org Subject: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi: The following is a review of draft-ietf-speechsc-mrcpv2-15 with emphasis on S1-S5, S12 and S14. There are a few general comments first; the rest of the comments follow in linear fashion with respect to the sections enumerated above. General comment 1: ------------------ A general comment I have is what is the relationship of MRCPv2 with RTSP? Both of these seem to provide some similar functionality, such as a recording resource. Also, RFC4463, the precursor to MRCPv2 appears to discuss RTSP more than this document does. In this document, SIP essentially replaces RTSP as the preferred protocol to establish a control session. This is fine, but it would seem to me that the average reader familiar with RTSP may benefit from some thoughts about the relationship of MRCPv2 to RTSP. General comment 2: ------------------ Another general comment I have concerns the SIP message flow in S4.2. There are a number of tactical omissions and implicit assumptions in that call flow that are repeated in the call flows of other sections as well. I will list these out for S4.2 and trust that the authors will retrofit other sections based on this discussion. 1. On page 15, when the C->S, the R-URI of the request is shown as sip:mresources@server.example.com. While this is not inaccurate, what will typically happen in SIP is that the initial request is targeted to a domain (i.e., sip:mresources@example.com) instead of a specific server within that domain (i.e., sip:mresources@server.example.com). Once the SIP dialog has been established, subsequent requests will contain a R-URI that is reflective of the specific server within that domain. Thus, on the very first request of a dialog-forming method like INVITE, you may want to consider changing the R-URI to reflect the domain URI of "sip:mresources@example.com". When that server replies with a 200 OK, the Contact URI of that response will contain a FQDN (i.e., "sip:mresources@server.example.com") -- and this is indeed the case in your call flow (see 200 OK on Page 16.) Note that subsequent requests in the dialog will contain a R-URI that corresponds to the FQDN of the server. Thus, in S4.2, at the end of page 16, the R-URI of the server is accurately shown as being "sip:mresources@server.example.com". 2. On page 15, the Contact URI of the initial INVITE request should contain a specific client within that domain. That is, the Contact URI must be "sip:sarvi@client.example.com" and not "sip:sarvi@example.com". 3. In SIP, a LWS is used to denote continuation. Thus, instead of writing: Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf9 you must instead write: Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf9 Note the LWS on the second line above. 4. In SIP, when a server responds with an affirmative response, it always adds a tag parameter to the From header. In the call flow on page 16, the From header of the 200 OK does not contain a tag parameter, it must. Interestingly enough, the subsequent ACK request contains the tag in the From parameter (as indeed it should.) Please add a tag parameter to the From header in the 200 OK, and ensure that it matches the one in the ACK request. The tags are maintained for the duration of the lifetime of that dialog. Thus, in the re-INV that starts at the bottom of page 16, the From tag must be maintained. Aside: the second m= line in the 200 OK body should have one 0 (i.e., s/00/0). 5. In SIP, the CSeq number of the ACK is kept the same as the preceding INVITE. Thus, on page 16 the CSeq number of the ACK request must be 314161. General comment 3: ------------------ In S6.1.1, page 29, there is an example message: MRCP/2.0 124 SET-PARAMS 543256 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:female Voice-variant:3 The second token (124) refers to the message length of the message, including the message body, if any. In the above example, if I assume that each line is terminated by a '\n' and a '\r\n' terminates the message itself, then I come up with a message length of 115 octets, which does not match the value shown above of 124. I would advise that, for the sake of completeness, the message-length field matches the actual value of the number of octets in the message for this example as well as the rest of the examples in the draft, including the examples in S14. As another example, take a look at the S->C message at the end of page 42 in S7. I calculate the payload length to be 291 octets, which does not match the Content-Length field value of 269 in the example. I would advise that, for the sake of completeness, the Content-Length field value matches the actual value of the number of octets in the SIP message body for this example as well as the rest of the examples in the draft. General comment 4: ------------------ The state machines in the draft are depicted as a time-flow diagram -- this is interesting. While I have not seen a state machine depicted as such -- all of the ones I am used to employ the canonical vertex and edges between them to signify transitions -- if a time-flow diagram suffices for the population reading the draft, then I am perfectly fine with leaving it in as is. I will depend on your discretion to strike out this comment if the depiction of the state machine is consistent with reader expectations. Rest of my comments follow: - Abstract: It is stated that MRCPv2 "relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery." True, SIP is a rendezvous protocol, but in and of itself, it is not a (media) capability discovery protocol; SDP is probably closer to the mark for (media) capability discovery and description (incidentally, SDP is mentioned in the immediate next sentence.) I would suggest a modest re-write, something along these lines: OLD: - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP ... NEW: - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 client and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP ... - S1, second paragraph: It is stated that "In addition, the client can use a SIP re-INVITE method (an INVITE dialog sent within an existing SIP Session) to change the characteristics of these media and control session while maintaining the SIP dialog between the client and server." It is true that you can use re-INV to do what is mentioned. However, I am curious: did you consider the UPDATE method? It also allows a client to update the parameters of a session, but is lightweight than the re-INV (for instance, it does not require an ACK, and does not require the server to keep retransmission state of the response until it gets an ACK.) Now, using a re-INV for offer/answer is sometimes advantageous in situations where, for instance, the sender wants to send a re- INV but does not specify any offer in it. The receiver sends an offer in the 2xx, and the sender answers that offer in the ACK. But I do not see MRCPv2 using such an exchange in the call flows present in the document. These call flows are of the normal pattern of "offer in request, answer in response". I realize that call flows do not normatively reflect the text, but if MRCPv2 can benefit from some reduced complexity by using a UPDATE/200 to change the session characteristics, then why not think about it? I will leave the final decision to you. - S1, third paragraph, first line: consider taking out the phrase "client/server" from the sentence. In SIP, once a dialog is set up, either end can act as a client. - S2.1: There appears to be some formatting problems. The second column invariably starts at a line below the first column. S3.1: Same comment as above when describing the media processing resources. - S2.2: Given that the reader of this document has no idea (at this point in the document) what PENDING, IN-PROGRESS, or COMPLETE are, you may wish to consider moving this paragraph before the first state diagram, by which time these states would have been explained. Or alternatively, you may want to consider putting a forward reference to S5.3, where these states are defined. - S3, third paragraph: s/server using this/server on this/ - S3, third paragraph: You may want to put a forward reference to the framing issue when doing I/O over a stream transport. When I was reading this paragraph, it naturally occurred to me whether MRCPv2 provides framing (it does, and this is discussed in S5.) Same comment as above for the opening paragraph of S4. - S3.1, in the definition of a Recorder: s/A resource capable of recording audio and saving it to a URI./A resource capable of recording audio and saving it as resource accessible by a URI./ - S3.1, in the defintion of a Recorder, second line: s/end pointing// - S3.2: the opening paragraph can best be re-written as follows: The MRCPv2 server is a generic SIP server, and is thus addressed by a SIP URI, for example: sip:mrcpv2@example.net. This is more concise, and I believe sufficient. How this address is resolved to reach the SIP server, and how that SIP server registers with its registrar are all handled by rfc3261. I do not see any advantage of discussing SIP registrars and Contact URIs here. - S4.1, third line: s/SIP transactions/SIP requests/ - S4.3, page 21: s/and fork it/and give it/ - S4.3, last paragraph: I am always a proponent of better error diagnostics. Thus, instead of putting the stock reason-phrase of "Not Implemented" on the 501 status-code, why not be more descriptive and put a reason-phrase of "Cannot mix/multimix or fork media"? That allows the automata to consume the 501 status-code as intended, but also allows for a descriptive reason-phrase to be displayed to the user. - S5.1, page 22: In the ABNF for generic-message, the generic- header production rule is not expanded until S6.2. I would suggest that it be expanded in S5.1, along with the resource- header production rule, or barring that, at least a forward reference to S6.2 be maintained to let the reader quickly find where generic-header is expanded. - S5.1: It may be best to move the discussion of the message-length field on page 23 to S5.2. It fits better there since the token is described in S5.2. Otherwise, you straddle critical information in between two sections and the reader has to go back and forth to make sense (BTW, FWIW, I am glad you have this field; framing is made much easier and code can be optimized by having it.) Same comment for mrcp-version production rule; describe it in S5.2 as well. - S5.2: I think it may be best if you describe the fields in the order that they appear in the request-line production rule. So, describe mrcp-version production rule first, followed by message-length, and so on. And consider consolidating the description of mrcp-version and message-length from S5.1 to this section (see previous comment.) As an added incentive to do this, note that in S5.3, the order of description matches the order in which the tokens appear in the response-line production rule. - S5.4: I note that you have some sort of an asynchronous notification system of responses (i.e., a PENDING or IN-PROGRESS indicates further Event messages will be delivered.) Why not have an specific status-code to that effect? In SIP, we have the notion of a "202 Accepted" response, which indicates that a request has been accepted but yet to be fully processed. Would a 202 response code be valuable to MRCPv2? I cannot say for sure, but did want to point this out to you so you can make a judgment on whether this is indeed the case. If you would like to read up more on the semantics of the 202 response code in SIP, it is defined in rfc3265. - S5.5, first paragraph: s/The status value is COMPLETE/The request- state value is COMPLETE/ Also, same comment as in S5.2 about making sure that the description of the tokens in the event-line production rule match the order in which the tokens appear in the production rule. - S7: missing terminating period on the last sentence of the section (end of page 42.) - The state machines in the draft are depicted as a time-flow diagram -- this is interesting. While I have not seen a state machine depicted as such -- all of the ones I am used to employ the canonical vertex and edges between them to signify transitions -- if a time-flow diagram suffices for the population reading the draft, then I am perfectly fine with leaving it in as is. I will depend on your discretion to strike out this comment if the depiction of the state machine is consistent with reader expectations. - S12.3 - Does anything need to be said about how to key the SRTP stream? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 08 12:14:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI0a-0005gM-GU; Tue, 08 Jan 2008 12:13:00 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCI0Y-0005fn-Gt for sip-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:12:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI0X-0005fQ-EB; Tue, 08 Jan 2008 12:12:57 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI0U-0004Bj-Vc; Tue, 08 Jan 2008 12:12:57 -0500 X-IronPort-AV: E=Sophos;i="4.24,258,1196658000"; d="scan'208";a="82700040" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jan 2008 12:12:54 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m08HCsa5023261; Tue, 8 Jan 2008 12:12:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m08HCOqA022700; Tue, 8 Jan 2008 17:12:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:12:48 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:12:48 -0500 Message-ID: <4783AF11.9030406@cisco.com> Date: Tue, 08 Jan 2008 12:12:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 References: <478396EF.3090502@alcatel-lucent.com> In-Reply-To: <478396EF.3090502@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2008 17:12:48.0144 (UTC) FILETIME=[B13F6100:01C85219] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1259; t=1199812374; x=1200676374; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-speech sc-mrcpv2-15 |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=UCtKtK0nNofSnkxkkIES1fcmqPxXZ6/RikTWjhmg1vI=; b=ZtOm8gTe+uWE7rrQna4eyu6UNFzr0f5XnDfAzlnXCVchX2OwK8GaLBgHX/ oaDP5BtpziTGrnvckHvpypNJBSMhvDQvLGwUiNI2/01kEEaJfm/GxesxTCOH 8j9m9ftd8q; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dburnett@voxeo.com, IETF SIP List , sarvi@cisco.com, speechsc-chairs@tools.ietf.org, speechsc@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, A very thorough review. I have one comment on it, below. Thanks, Paul Vijay K. Gurbani wrote: > Hi: > > The following is a review of draft-ietf-speechsc-mrcpv2-15 with > emphasis on S1-S5, S12 and S14. There are a few general comments > first; the rest of the comments follow in linear fashion with respect > to the sections enumerated above. [snip] > 4. In SIP, when a server responds with an affirmative response, > it always adds a tag parameter to the From header. Don't you mean To: header? The initial INVITE should have a From-tag and the response should contain that and a To-tag. All subsequent requests and responses in the dialog should have both. > In the call > flow on page 16, the From header of the 200 OK does not contain > a tag parameter, it must. Interestingly enough, the subsequent > ACK request contains the tag in the From parameter (as indeed it > should.) Please add a tag parameter to the From header in the > 200 OK, and ensure that it matches the one in the ACK request. > The tags are maintained for the duration of the lifetime of that > dialog. > > Thus, in the re-INV that starts at the bottom of page 16, the > From tag must be maintained. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 08 12:16:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI3J-0006nO-Ce; Tue, 08 Jan 2008 12:15:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCI3I-0006ls-3U for sip-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:15:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI3H-0006lZ-Fr; Tue, 08 Jan 2008 12:15:47 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI3H-0004Ef-5C; Tue, 08 Jan 2008 12:15:47 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m08HFfid029515; Tue, 8 Jan 2008 11:15:41 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m08HFgj05609; Tue, 8 Jan 2008 11:15:42 -0600 (CST) Message-ID: <4783AFBD.50905@alcatel-lucent.com> Date: Tue, 08 Jan 2008 11:15:41 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 References: <478396EF.3090502@alcatel-lucent.com> <4783AF11.9030406@cisco.com> In-Reply-To: <4783AF11.9030406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dburnett@voxeo.com, IETF SIP List , sarvi@cisco.com, speechsc-chairs@tools.ietf.org, speechsc@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Vijay, > > A very thorough review. I have one comment on it, below. > > > Vijay K. Gurbani wrote: > >> 4. In SIP, when a server responds with an affirmative response, >> it always adds a tag parameter to the From header. > > Don't you mean To: header? Paul: Yes, my bad. Thanks for catching this. Indeed, I meant the To header. > The initial INVITE should have a From-tag and the response should > contain that and a To-tag. All subsequent requests and responses in the > dialog should have both. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 04:58:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXhT-0006AX-Vb; Wed, 09 Jan 2008 04:58:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCXhR-0006AR-Qu for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 04:58:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXhR-0006AJ-HG for sip@ietf.org; Wed, 09 Jan 2008 04:58:17 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCXhP-0003Y4-Oo for sip@ietf.org; Wed, 09 Jan 2008 04:58:17 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUD0028JFP2X0@siemenscomms.co.uk> for sip@ietf.org; Wed, 09 Jan 2008 09:58:14 +0000 (GMT) Date: Wed, 09 Jan 2008 09:58:14 +0000 From: "Elwell, John" To: Hadriel Kaplan , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05494DD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: draft-kaplan-sip-info-use-cases-00 - more use cases? thread-index: AchSpiZDCF97hFP6TcKuyYas45XMSw== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, Some possible further use cases: 1. Along the same lines as 6.2/6.3/6.4 (vcard, user-icon, vcalendar), we could also consider pictures, movie clips, audio clips, etc.. Of course, we don't want to encourage sending anything too big along the signalling path, so we would need to consider where to draw the line. 2. We already have the conference event package for obtaining conference membership details. In many situations the conference focus is also the source of such notifications, so the subscribe-initiated dialog parallels the INVITE-initiate dialog, which is rather wasteful. It would be great to subscribe as part of the INVITE transaction and receive notifications along the INVITE-initiated dialog. 3. Concerning mobility, I like the suggestion in 6.8 (geo-location information). Also, there may sometimes be intermediaries on the signalling path (B2BUAs) that are involved in mobility in some way, and these might be interested in movement-related notifications (e.g., a dual mode device moving in or out of WLAN range). 4. The use of offer-answer to achieve hold-retrieve fails to give an explicit indication of what is happening. An explicit indication of things like hold, retrieve, microphone mute, speaker mute, camera on/off, recorder on/off, etc. might be quite helpful. Of course, there will normally be an offer-answer exchange at the same time, so inclusion of the notification in a re-INVITE or UPDATE request might be more useful than using INFO. 5. Concerning 6.7 (soft-key labels), a problem here is that the notifying UA might not have knowledge of soft key availability at the receiving UA. In certain closed environments (e.g., involving a UA and its local voicemail server) it may work, but I am not sure it would work well in general. Having said that, where it does work, perhaps other parameters at the device can be controlled in this way, e.g., microphone and speaker volume (especially if this control is based on say a web interface, so the user is really controlling his/her own settings from the web page rather than directly on the device). 6. When a B2BUA performs 3PCC there is plenty of scope for the UAs to lose track of what is happening. For example, when a B2BUA holds, retrieves, transfers calls, joins calls, pre-empts calls, etc., there is currently no explicit information - only perhaps a re-INVITE request. Thus it can be difficult to know how to interpret things like identity. Say a UA receives a re-INVITE request with a new PAI, it might deduce that something like call transfer has occurred. However, if it receives a re-INVITE request without a PAI, does it mean the previous PAI is still valid, or does it mean, following transfer, there is no longer any identity available? Of course, INFO might not always be the most appropriate method to use for such notification if an offer-answer exchange is needed at the same time. 7. There might be some usages to do with interworking with TDM, e.g., advice of charge during a call, user-to-user information during a call. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 05:25:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCY6t-00082s-3Z; Wed, 09 Jan 2008 05:24:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCY6r-00082k-QA for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 05:24:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCY6r-00082c-GO for sip@ietf.org; Wed, 09 Jan 2008 05:24:33 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCY6p-0003q4-HQ for sip@ietf.org; Wed, 09 Jan 2008 05:24:33 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1BB4B20FCE; Wed, 9 Jan 2008 11:24:30 +0100 (CET) X-AuditID: c1b4fb3c-ae794bb0000030cf-41-4784a0dd6e74 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E1A8020FC7; Wed, 9 Jan 2008 11:24:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 11:24:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2008 11:24:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on RFC3840/3841 Thread-Index: AchSqdCJKYigmvGbQKur5T6uMaNzfg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 09 Jan 2008 10:24:29.0507 (UTC) FILETIME=[D155C930:01C852A9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Paul Kyzivat Subject: [Sip] Question on RFC3840/3841 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Chapter 9 of RFC3840 says: "There are additional constraints on the usage of feature-param that cannot be represented in a BNF. There MUST only be one instance of any feature tag in feature-param." Chapter 10 of RFC3840 says: "Furthermore, there can only be one instance of any feature tag in feature-param." So, this means that the following is NOT allowed: Accept-Contact: *;myTag,myTag However, since an Accept-Contact header can contain multiple ac-values, each with its own sets of ac-parameters (including feature-params), the following should be allowed: Accept-Contact: *;myTag, *;myTag ...or: Accept-Contact: *;myTag Accept-Contact: *;myTag Correct? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 07:36:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaAf-0001bF-0a; Wed, 09 Jan 2008 07:36:37 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCaAd-0001b9-3a for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 07:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaAc-0001b1-Q4 for sip@ietf.org; Wed, 09 Jan 2008 07:36:34 -0500 Received: from inmumg01.tcs.com ([219.64.33.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCaAb-0005gn-GL for sip@ietf.org; Wed, 09 Jan 2008 07:36:34 -0500 X-IronPort-AV: E=Sophos;i="4.24,262,1196620200"; d="scan'208,217";a="137896540" Received: from unknown (HELO inmumm13.tcs.com) ([172.17.9.193]) by inmumg01.tcs.com with ESMTP; 09 Jan 2008 18:06:27 +0530 In-Reply-To: <52db68bc0712202020s106bc26cv923b17613055c51c@mail.gmail.com> From: Vin Sharma To: "Sudhir Kumar Reddy" Subject: Re: [Sip] 200 OK in calling state for INVITE client transaction MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 9 Jan 2008 18:06:25 +0530 X-MIMETrack: Serialize by Router on InMumM13/TCS(Release 6.5.5FP2HF415 | June 20, 2007) at 01/09/2008 18:06:27, Serialize complete at 01/09/2008 18:06:27 X-Spam-Score: -4.0 (----) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0240295800==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0240295800== Content-Type: multipart/alternative; boundary="=_alternative 00453E50652573CB_=" This is a multipart message in MIME format. --=_alternative 00453E50652573CB_= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Sudhir, ACK must contain the same To- tag as recevied in 200 OK for invite, because to-tag is used to identify dialog for which this ACK is received. Regards, Vinay Sharma Tata Consultancy Services Mailto: vin.sharma@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ "Sudhir Kumar Reddy" 12/21/2007 09:50 AM To sip@ietf.org cc Subject [Sip] 200 OK in calling state for INVITE client transaction Hi All, when an INVITE client transaction is in the Calling state, on receipt of Success (200 OK) response. As per RFC 17.1.1.2(Figure 5: INVITE client transaction), the 2xx response MUST cause the client transaction to enter the "Terminated" state. But, I'm not sure what would be To_Tag in generating ACK for that 200 OK. Any response is highly appericated. Thanks, Sudhir_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ForwardSourceID:NT00015056 =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 00453E50652573CB_= Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"
Hi Sudhir,

ACK must contain the same To- tag as recevied in 200 OK for invite, because to-tag is used to identify dialog for which this ACK is received.

Regards,
Vinay Sharma
Tata Consultancy Services
Mailto: vin.sharma@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
____________________________________________


"Sudhir Kumar Reddy" <t.sudhirkumar@gmail.com>

12/21/2007 09:50 AM

To
sip@ietf.org
cc
Subject
[Sip] 200 OK in calling state for INVITE client transaction





Hi All,

when an INVITE client transaction is in the Calling state, on receipt of Success (200 OK) response. As per RFC 17.1.1.2(Figure 5: INVITE client transaction), the 2xx response MUST cause the client transaction to enter the "Terminated" state. But, I'm not sure what would be To_Tag in generating ACK for that 200 OK.

Any response is highly appericated.

Thanks,
Sudhir_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
ForwardSourceID:NT00015056     
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you
--=_alternative 00453E50652573CB_=-- --===============0240295800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0240295800==-- From sip-bounces@ietf.org Wed Jan 09 08:28:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCayR-0007aK-F2; Wed, 09 Jan 2008 08:28:03 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCayP-0007Zq-Om for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 08:28:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCayP-0007Zb-Dj for sip@ietf.org; Wed, 09 Jan 2008 08:28:01 -0500 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCayO-0001hU-Te for sip@ietf.org; Wed, 09 Jan 2008 08:28:01 -0500 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JUD00HXFPEID5@mailout1.samsung.com> for sip@ietf.org; Wed, 09 Jan 2008 22:27:54 +0900 (KST) Received: from mahesha ([107.108.74.189]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JUD00FMLPEH2C@mmp2.samsung.com> for sip@ietf.org; Wed, 09 Jan 2008 22:27:54 +0900 (KST) Date: Wed, 09 Jan 2008 19:00:36 +0530 From: Mahesh Anjanappa Subject: Re: [Sip] Question on RFC3840/3841 To: Christer Holmberg , sip@ietf.org Message-id: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org hi That is my understanding as well. But if that is the case then it should apply to Contact header as well when describing Capabilities using Feature parameters in Contact Header. But i'm not sure if it applies the same way. I had posted this question long ago but didnt get any comments on it. regards Mahesh ----- Original Message ----- From: "Christer Holmberg" To: Cc: "Paul Kyzivat" Sent: Wednesday, January 09, 2008 3:54 PM Subject: [Sip] Question on RFC3840/3841 Hi, Chapter 9 of RFC3840 says: "There are additional constraints on the usage of feature-param that cannot be represented in a BNF. There MUST only be one instance of any feature tag in feature-param." Chapter 10 of RFC3840 says: "Furthermore, there can only be one instance of any feature tag in feature-param." So, this means that the following is NOT allowed: Accept-Contact: *;myTag,myTag However, since an Accept-Contact header can contain multiple ac-values, each with its own sets of ac-parameters (including feature-params), the following should be allowed: Accept-Contact: *;myTag, *;myTag ...or: Accept-Contact: *;myTag Accept-Contact: *;myTag Correct? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 09:21:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCboO-00085I-Uf; Wed, 09 Jan 2008 09:21:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCboO-00085C-Ab for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 09:21:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCboN-00082q-V9 for sip@ietf.org; Wed, 09 Jan 2008 09:21:44 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCboN-0003nV-Mi for sip@ietf.org; Wed, 09 Jan 2008 09:21:43 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2008 09:21:43 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m09ELh26031361; Wed, 9 Jan 2008 09:21:43 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m09ELc6p002808; Wed, 9 Jan 2008 14:21:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 09:21:39 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 09:21:39 -0500 Message-ID: <4784D875.7080508@cisco.com> Date: Wed, 09 Jan 2008 09:21:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2008 14:21:39.0369 (UTC) FILETIME=[F2FE6990:01C852CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=973; t=1199888503; x=1200752503; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Question=20on=20RFC3840/3841 |Sender:=20 |To:=20Christer=20Holmberg=20; bh=QbLVTARsIx4h0PQJSB03szTo0EIym5JMC+Q/Tg9j6xg=; b=xqeGhf05CCK1gcbKe4FxftZg2qR0ythCSU4yAARaH01eIVNpwL168pvQmV Hn+IsurD6QIrZx/SYVwB3AHl5WUZFVyfcMMv2yS3ipSAt0aEyD3UOdI9VKRY U3srJCmd66; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org Subject: [Sip] Re: Question on RFC3840/3841 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > > > Chapter 9 of RFC3840 says: > > "There are additional constraints on the usage of feature-param that > cannot be represented in a BNF. There MUST only be one instance of any > feature tag in feature-param." > > > Chapter 10 of RFC3840 says: > > "Furthermore, there can only be one instance of any feature tag in > feature-param." > > > > So, this means that the following is NOT allowed: > > Accept-Contact: *;myTag,myTag The above isn't syntactically correct. I presume you meant to write: Accept-Contact: *;myTag;myTag And yes, that isn't allowed. > However, since an Accept-Contact header can contain multiple ac-values, > each with its own sets of ac-parameters (including feature-params), the > following should be allowed: > > Accept-Contact: *;myTag, *;myTag > > ...or: > > Accept-Contact: *;myTag > Accept-Contact: *;myTag > > > Correct? Yes. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 09:26:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCbsh-0001Ih-1g; Wed, 09 Jan 2008 09:26:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCbsf-0001Ic-GF for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 09:26:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCbsf-0001IU-6X for sip@ietf.org; Wed, 09 Jan 2008 09:26:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCbsd-0000Le-RW for sip@ietf.org; Wed, 09 Jan 2008 09:26:09 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2008 09:26:07 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m09EQ7Lp001108; Wed, 9 Jan 2008 09:26:07 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m09EQ2pk007228; Wed, 9 Jan 2008 14:26:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 09:25:45 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 09:25:44 -0500 Message-ID: <4784D96A.5010104@cisco.com> Date: Wed, 09 Jan 2008 09:25:46 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mahesh Anjanappa Subject: Re: [Sip] Question on RFC3840/3841 References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> In-Reply-To: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2008 14:25:44.0938 (UTC) FILETIME=[855D44A0:01C852CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=562; t=1199888767; x=1200752767; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20RFC3840/3841 |Sender:=20 |To:=20Mahesh=20Anjanappa=20; bh=7h+fdhur1gPoPDfi1Wma91Sgv9+tDTpRFul9lJvjngk=; b=gBA9X4o3fIM9UJi8D7GvqwUhTl9CiARgkMmX2SqRS0qmh2gJsnr0WX4Uav wewxf4Rt/P2xQrJscLUz/SOGaT220HX1El7bViR1VeLJCjGS0pUo3Av8W8BD gqimpukQWr; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mahesh Anjanappa wrote: > hi > That is my understanding as well. But if that is the case then it should > apply to Contact header as well > when describing Capabilities using Feature parameters in Contact Header. > But i'm not sure if it applies the same way. I had posted this question > long ago but didnt get any comments on it. The rule forbidding multiple instances of a parameter applies to all headers, so it applies to Contact. E.g. the following is illegal: Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 11:32:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdqI-00013z-KT; Wed, 09 Jan 2008 11:31:50 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCdqG-00013t-Ms for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 11:31:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCdqG-00013l-Bt for sip@ietf.org; Wed, 09 Jan 2008 11:31:48 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCdqF-0001zJ-Tr for sip@ietf.org; Wed, 09 Jan 2008 11:31:48 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m09GVcRX001917 for ; Wed, 9 Jan 2008 10:31:45 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 10:31:41 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 17:31:39 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2008 17:31:39 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delivering request-URI and parameters to UAS via proxy Thread-index: Acg2ih6i4UTKPgVSQf2WFbiy3Qsq9wcUuLeA From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Jan 2008 16:31:39.0883 (UTC) FILETIME=[1C7663B0:01C852DD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] RE: Delivering request-URI and parameters to UAS via proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A reminder of the deadline on the 11th January for submitting alternative proposals on the way forward. Regards Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: Tuesday, December 04, 2007 3:27 PM > To: sip@ietf.org > Subject: Delivering request-URI and parameters to UAS via proxy >=20 > (As WG chair) >=20 > We have a couple of milestones that we generated as a result=20 > of discussion of=20 >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > se-route-01.txt >=20 > Dec 2007 Delivering request-URI and parameters to UAS via=20 > proxy to WGLC =20 > Feb 2008 Delivering request-URI and parameters to UAS via=20 > proxy to IESG (PS) =20 >=20 > This work is currently stalled and the editor needs input. >=20 > The document contains various example scenarios where a=20 > solution is required, for which there appears to be no=20 > dispute that a solution is needed. >=20 > The document proposes one solution to resolve these example=20 > scenarios, but this solution is not gaining consensus. At=20 > least one other solution has been talked about, but there is=20 > no documentation on the table. >=20 > This mail is to identify a deadline for other solutions to=20 > the example scenarios to be documented as internet drafts,=20 > showing how the solution works for those scenarios. This deadline is: >=20 > January 11th 2008 >=20 > It is appropriate fo these documents to identify any other=20 > scenarios where such a solution is appropriate. Any other=20 > input is also welcome in identifying other scenarios. >=20 > If we have no such internet-drafts by this deadline, we will=20 > proceed with completing the solution we have. >=20 >=20 > Regards >=20 > Keith >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 12:16:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCeWz-0001C0-2N; Wed, 09 Jan 2008 12:15:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCeWx-00018p-Rh for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 12:15:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCeWx-00018S-Gk for sip@ietf.org; Wed, 09 Jan 2008 12:15:55 -0500 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCeWw-0003B8-H8 for sip@ietf.org; Wed, 09 Jan 2008 12:15:55 -0500 Received: from epmmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JUD00977ZY856@mailout1.samsung.com> for sip@ietf.org; Thu, 10 Jan 2008 02:15:44 +0900 (KST) Received: from mahesha ([107.108.74.189]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JUD00I06ZY7DP@mmp1.samsung.com> for sip@ietf.org; Thu, 10 Jan 2008 02:15:44 +0900 (KST) Date: Wed, 09 Jan 2008 22:48:26 +0530 From: Mahesh Anjanappa Subject: Re: [Sip] Question on RFC3840/3841 To: Paul Kyzivat Message-id: <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Paul. So would it be right if i have a Contact Headers describing Duplex Audio & one-way Video Capabilities as follows? Contact:sip:alice@atlanta.com; Contact:sip:audio;duplex=full; Contact:sip:video;duplex=recieve-only; NOTE: The Predicate(for above) for which i'm attempting is & ( & (sip.audio) (sip.duplex=full) ) ( & (sip.video) (sip.duplex=receive-only) ) regards Mahesh ----- Original Message ----- From: "Paul Kyzivat" To: "Mahesh Anjanappa" Cc: "Christer Holmberg" ; Sent: Wednesday, January 09, 2008 7:55 PM Subject: Re: [Sip] Question on RFC3840/3841 > > > Mahesh Anjanappa wrote: >> hi >> That is my understanding as well. But if that is the case then it should >> apply to Contact header as well >> when describing Capabilities using Feature parameters in Contact Header. >> But i'm not sure if it applies the same way. I had posted this question >> long ago but didnt get any comments on it. > > The rule forbidding multiple instances of a parameter applies to all > headers, so it applies to Contact. E.g. the following is illegal: > > Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" > > Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 13:36:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfmW-0005jd-DN; Wed, 09 Jan 2008 13:36:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCfmV-0005hF-7I for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 13:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfmU-0005h6-Tg for sip@ietf.org; Wed, 09 Jan 2008 13:36:02 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCfmU-0007sV-KH for sip@ietf.org; Wed, 09 Jan 2008 13:36:02 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0AC58204A8; Wed, 9 Jan 2008 19:36:02 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-5c-478514112e0f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D8A3E207C0; Wed, 9 Jan 2008 19:36:01 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 19:36:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2008 19:34:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on RFC3840/3841 Thread-Index: AchSzBq1jJI0SVz/Ts2YtJ3bh1GVwAAIiICw References: <4784D875.7080508@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 09 Jan 2008 18:36:01.0729 (UTC) FILETIME=[7C11BB10:01C852EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org Subject: [Sip] RE: Question on RFC3840/3841 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >>Chapter 9 of RFC3840 says: >> >>"There are additional constraints on the usage of feature-param that >>cannot be represented in a BNF. There MUST only be one instance of any >>feature tag in feature-param." >> >> >>Chapter 10 of RFC3840 says: >> >>"Furthermore, there can only be one instance of any feature tag in = feature-param." >> >> >> >>So, this means that the following is NOT allowed: >> >>Accept-Contact: *;myTag,myTag > >The above isn't syntactically correct. I presume you meant to write: > >Accept-Contact: *;myTag;myTag Yes. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 14:01:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgAD-0008JV-MH; Wed, 09 Jan 2008 14:00:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCgAB-0008IB-NJ for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 14:00:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgAB-0008Hy-87 for sip@ietf.org; Wed, 09 Jan 2008 14:00:31 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCgAA-0006Sj-1r for sip@ietf.org; Wed, 09 Jan 2008 14:00:31 -0500 Received: by fg-out-1718.google.com with SMTP id 16so361599fgg.41 for ; Wed, 09 Jan 2008 11:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=wx+/RiTjtYfXbVMrRXDvZwjaMuL44ZYLPuFhesNlUwo=; b=v/Q5DdmMyEs5yfxTm/TSt42GTLAJUxUd0GKPj0AEp+AVWIhU6nmpj5GdmzN8J5irdRS6LxhTjMLkE6Dp6fOF/Fw8a22Cg3fhNXeLki+92CkgAKJBVa9wXKNq+X5t4Jcd4dvCrk5hayx/mP3uk3jsyBicPcqOpHk3h4oxRfHg1xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=HKU8cStWisyNSGu5GIpoeeCGoPTs+mPXPlsaLwnMDwVvuEVAEfnfu6Gg8Hk9TOMaBYs5OK+2VXajyZNGdy12hC5Pei7tWL6j7AU76UDpl/CLeqLWF8p4Z8LsWHQW9o01I2SqH9pnEZWsTBFq+8e9wtQSOvaXhNNlcWhfWf82fNM= Received: by 10.86.86.12 with SMTP id j12mr927404fgb.68.1199905229368; Wed, 09 Jan 2008 11:00:29 -0800 (PST) Received: by 10.86.61.5 with HTTP; Wed, 9 Jan 2008 11:00:29 -0800 (PST) Message-ID: Date: Thu, 10 Jan 2008 02:00:29 +0700 From: "Jati Kalingga Praja" To: sip@ietf.org, sip-implementors@lists.cs.columbia.edu, megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10989_26389566.1199905229342" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 Cc: Subject: [Sip] Translation Megaco 2 SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ------=_Part_10989_26389566.1199905229342 Content-Type: multipart/alternative; boundary="----=_Part_10990_23010512.1199905229343" ------=_Part_10990_23010512.1199905229343 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,, Right now, i'm studying about interworking between megaco and sip. Here i attached the call flow diagram which i have concluded from my study. But i found some questions here : 1. Look at the attached file, if i want to count delay translation from megaco to sip "INVITE" message, which megaco message that i must use as the time reference to count the delay?Is it notify digits or notify digits response or add response? 2. Loot at the part of before the RTP, there is 3. Loot at the end part of the attached file, theoritically, when the analog phone onhooked first, MGC must send the BYE message to the SIP phone, don't it?,,,then, why did the SIP phone sent the BYE message? Thx before in advance,,, Best Regards, Jati ------=_Part_10990_23010512.1199905229343 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,,

Right now, i'm studying about interworking between megaco and sip. Here i attached the call flow diagram which i have concluded from my study. But i found some questions here :
1. Look at the attached file, if i want to count delay translation from megaco to sip "INVITE" message, which megaco message that i must use as the time reference to count the delay?Is it notify digits or notify digits response or add response?
2. Loot at the part of before the RTP, there is
3. Loot at the end part of the attached file, theoritically, when the analog phone onhooked first, MGC must send the BYE message to the SIP phone, don't it?,,,then, why did the SIP phone sent the BYE message?

Thx before in advance,,,

Best Regards,


Jati
------=_Part_10990_23010512.1199905229343-- ------=_Part_10989_26389566.1199905229342 Content-Type: application/msword; name="megaco2sip interworking.doc" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fb86a73q0 Content-Disposition: attachment; filename="megaco2sip interworking.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARQAAAAAAAAAA EAAARwAAAAEAAAD+////AAAAAEQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAeYAJBAAA+BK/AAAAAAAAEAAAAAAACAAApwoAAA4AYmpiakXqReoAAAAAAAAAAAAAAAAAAAAA AAAJBBYALhYAACeAAAAngAAAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiQIAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAJgFAAAAAAAAmAUAANsS AAAAAAAA2xIAAAAAAAAXGAAAAAAAABcYAAAAAAAAFxgAABQAAAAAAAAAAAAAAP////8AAAAAKxgA AAAAAAArGAAAAAAAACsYAAAAAAAAKxgAABQAAAA/GAAAHAAAACsYAAAAAAAAkToAADABAABbGAAA FgAAAHEYAAAAAAAAcRgAAAAAAABxGAAAAAAAAHEYAAAAAAAAFDkAAAAAAAAUOQAAAAAAABQ5AAAA AAAAEDoAAAIAAAASOgAAAAAAABI6AAAAAAAAEjoAAAAAAAASOgAAAAAAABI6AAAAAAAAEjoAACQA AADBOwAAogIAAGM+AAB2AAAANjoAABUAAAAAAAAAAAAAAAAAAAAAAAAAFxgAAAAAAAAUOQAAAAAA AAAAAAAAAAAAAAAAAAAAAADyOAAAIgAAABQ5AAAAAAAAFDkAAAAAAAAUOQAAAAAAADY6AAAAAAAA AAAAAAAAAADbEgAAAAAAANsSAAAAAAAAcRgAAAAAAAAAAAAAAAAAAHEYAACBIAAASzoAABYAAADc OQAAAAAAANw5AAAAAAAA3DkAAAAAAAAUOQAAlAAAANsSAADGAwAAcRgAAAAAAAAXGAAAAAAAAHEY AAAAAAAAEDoAAAAAAAAAAAAAAAAAANw5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFDkAAAAAAAAQOgAAAAAAAAAAAAAAAAAA3DkAAAAAAAAAAAAA AAAAANw5AAAAAAAAoRYAAHYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3DkAAAAAAABxGAAAAAAAAP////8AAAAAwFtIm+hS yAEAAAAAAAAAACsYAAAAAAAAqDkAADQAAADcOQAAAAAAAAAAAAAAAAAA/DkAABQAAABhOgAAMAAA AJE6AAAAAAAA3DkAAAAAAADZPgAAAAAAANw5AAAAAAAA2T4AAAAAAADcOQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAANk+AAAAAAAAAAAAAAAAAAAXGAAAAAAAANw5AAAgAAAAFDkAAAAAAAAUOQAAAAAAANw5 AAAAAAAAFDkAAAAAAAAUOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFDkA AAAAAAAUOQAAAAAAABQ5AAAAAAAANjoAAAAAAAA2OgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA3DkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ5AAAA AAAAFDkAAAAAAAAUOQAAAAAAAJE6AAAAAAAAFDkAAAAAAAAUOQAAAAAAABQ5AAAAAAAAFDkAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAANk+AAAAAAAAFDkAAAAAAAAU OQAAAAAAABQ5AAAAAAAAFDkAAAAAAAAUOQAAAAAAABQ5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUOQAAAAAAABQ5AAAAAAAAFDkA AAAAAACYBQAACQwAAKERAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMgU0hB UEUgIFwqIE1FUkdFRk9STUFUIBQIARUNTW9kaWZ5IFJlc3BvbnNlDQ0xODMgU2Vzc2lvbiBQcm9n cmVzcyAoNikNDVJlcXVlc3Q6IElOVklURSAoNSkNDU5vdGlmeSBPZmZob29rICgxKQ0NTm90aWZ5 IFJlc3BvbnNlDQ1Nb2RpZnkgKG1vZGU6c2VuZHJlY3YpICg5KQ0NUlRQICgxMSkNDUJZRSAoMTQp DQ0yMDAgT0sgU0RQIChHLjcxMSkgKDgpDQ1BDQ1NR0MNDUINDU1vZGlmeSB0byBjaGVjayBvZmZo b29rDQ1Nb2RpZnkgKGRpYWx0b25lKSAoMikNDUFkZCBSZXNwb25zZQ0NTW9kaWZ5IFJlc3BvbnNl DQ1Ob3RpZnkgT25ob29rICgxMikNDU5vdGlmeSBSZXNwb25zZQ0NU3Vic3RyYWN0IChUZXJtIHAv MSwgRXBoIHAvMSkgKDEzKQ0NU3Vic3RyYWN0IFJlc3BvbnNlDQ1BZGQgKCQsIHRlcm0gcC8xLCBF cGggcC8xKSAoNCkNDU5vdGlmeSBEaWdpdHMgKDMpDQ1Ob3RpZnkgUmVzcG9uc2UNDTEwMCBUcnlp bmcNDUFDSw0NVHJhbnNhY3Rpb25SZXNwb25zZUFjaw0NTW9kaWZ5IFJlc3BvbnNlDQ1UcmFuc2Fj dGlvblJlc3BvbnNlQWNrDQ1Nb2RpZnkgKG1vZGU6cmVjdiBvbmx5KSAoNykNDU1vZGlmeSBSZXNw b25zZQ0NTW9kaWZ5IChzaWduYWw6e30pICgxMCkNDU1vZGlmeSBSZXNwb25zZQ0NVHJhbnNhY3Rp b25SZXNwb25zZUFjaw0NTW9kaWZ5DQ1Nb2RpZnkgUmVwbHkNDTIwMCBPSw0NDQ0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAQgA ABgIAAAcCAAAHQgAAC0IAAAuCAAARggAAEcIAABICAAAVwgAAFsIAABcCAAAXQgAAGsIAABvCAAA cAgAAHEIAACACAAAgQgAAIIIAACcCAAAnQgAAJ4IAAClCAAApwgAAKgIAACrCAAAsAgAALEIAACy CAAAxwgAAMkIAADKCAAAywgAAMwIAADNCAAA0AgAANEIAADSCAAA0wgAANQIAADVCAAA7QgAAO4I AAADCQAABAkAAAUJAAAICQAAEgkAABMJAAAiCQAAIwkAACQJAAA2CQAANwkAADgJAABHCQAASAkA AEkJAABrCQAAbAkAAG0JAAB/CQAAgAkAAIEJAACfCQAAoAkAAKEJAAD38/fz6vPk2/Pq5Orz0uTS 8+TJ8+TJ8+TA87fkt/PkyfPkwPPkwPPkwPPq8+Tq8+Tq8+TJ8+Su8+Su8+Su8+Su8+Tq8wAAAAAQ FWhdXN8AFmhUN0AAQ0oUAAAQFWgYUtsAFmhUN0AAQ0oUAAAQFWjvUSYAFmhUN0AAQ0oUAAAQFWhb WuQAFmhUN0AAQ0oUAAAQFWjFJM0AFmhUN0AAQ0oUAAAQFWiWdPUAFmhUN0AAQ0oUAAAKFmhUN0AA Q0oUAAAQFWhTE54AFmhUN0AAQ0oUAAAGFmhUN0AAAA8DagAAAAAWaFQ3QABVCAEARAAIAAAdCAAA LQgAAC4IAABHCAAASAgAAFwIAABdCAAAcAgAAHEIAACBCAAAgggAAJ0IAACeCAAApwgAAKgIAACx CAAAsggAAMkIAADKCAAAzAgAAM0IAADRCAAA0ggAANQIAADVCAAA7QgAAO4IAAAECQAA/QAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPAAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAAAHAAADJAFhJAFnZFQ3QAAABAAAZ2RUN0AAAAEAAAAcBAkAAAUJAAAS CQAAEwkAACMJAAAkCQAANwkAADgJAABICQAASQkAAGwJAABtCQAAgAkAAIEJAACgCQAAoQkAALMJ AAC0CQAAxAkAAMUJAADQCQAA0QkAANUJAADWCQAA7QkAAO4JAAD+CQAA/wkAABYKAAD9AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZFQ3QAAAAQAAAByhCQAAsgkAALMJ AAC0CQAAwwkAAMQJAADFCQAA0AkAANEJAADUCQAA1QkAANYJAADsCQAA7QkAAO4JAAD9CQAA/gkA AP8JAAAVCgAAFgoAABcKAAAyCgAAMwoAADQKAABDCgAARAoAAEUKAABcCgAAXQoAAF4KAABtCgAA bgoAAG8KAACFCgAAhgoAAIcKAACNCgAAjgoAAI8KAACbCgAAnAoAAJ0KAACjCgAApAoAAKUKAACm CgAApwoAAPrx7frk7dvt+tLt+uTt+snt+uTt+uTt+uTt+uTt+uTt+uTt+sDt+tLt+tLtvO0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZo62puAAAQFWgYUtsAFmhUN0AAQ0oUAAAQFWhTE54A FmhUN0AAQ0oUAAAQFWhdXN8AFmhUN0AAQ0oUAAAQFWiWdPUAFmhUN0AAQ0oUAAAQFWhbWuQAFmhU N0AAQ0oUAAAGFmhUN0AAABAVaMUkzQAWaFQ3QABDShQAAAoWaFQ3QABDShQALhYKAAAXCgAAMwoA ADQKAABECgAARQoAAF0KAABeCgAAbgoAAG8KAACGCgAAhwoAAI4KAACPCgAAnAoAAJ0KAACkCgAA pQoAAKYKAACnCgAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2RUN0AAAAEAAAATLAAxkGgBH7DQLyCw 4D0hsKAFIrCgBSOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAARABkAAAAAAAA AAIAAAAAAAAAAAAAAAAAcCHeMJsDGwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A BPBEAAAAsgQK8AgAAAABBAAAAAoAADMAC/ASAAAAfwBAAUABAAEQAP//AQHw/wAAEwAi8QYAAAA/ BQEAAQAAABDwBAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagQPABIAAQALAQ8ABwADAAMAAwAA AAQACAAAAJgAAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAAD4CAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAACoAAAANgYAADYGAAAWAAAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAC4AAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAAaAEAAEgBAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALADAAA2BgAA MgYAABgAAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACA BAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAADIGAAAoAgAA2AEAAOgBAAAgBAAAMAQAAEAE AABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQA AFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQ BAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQA AGAEAABwBAAAgAQAAJAEAAA4AQAAWAEAAPgBAAAIAgAAGAIAAFYCAAB+AgAAIAAAAE9KAwBQSgMA UUoDAF9IAQRtSAkEbkgJBHNICQR0SAkEAAAAAFAAAGDx/wIAUAAMEAAAVDdAAAAABgBOAG8AcgBt AGEAbAAAAAIAAAAoAENKGABPSgAAUEoAAFFKAABeSgAAX0gBBGFKGABtSAkEc0gJBHRICQQAAAAA AAAAAAAAAAAAAAAAAABEAEFg8v+hAEQADA0AAAAAAAAQABYARABlAGYAYQB1AGwAdAAgAFAAYQBy AGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/swBSAAwdAAAAAAAAMAYMAFQAYQBiAGwA ZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABr IPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAAFBLAwQUAAYACAAAACEA goq8E/oAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil2M6i SXd9LNIPGOSxLWqPhDQJyd937LhQuggtdCMQYs6Ze1Wuj+OgDhiT81TpVV5ohWR946ir9PvuKbvX KjFQA4MnrPQJk17X11fl7hQwKZmmVOmeOTwYk2yPI6TcByR5aX0cgeUaOxPAfkCH5rYo7oz1xEic 8cTQdfkqC0TXoHqDyC8wisewoPD7+QwkgJgLWKvHM2FaotIQwuAssEQwB2p+6DPfts5i4+1+FGk+ gxfYzQQzv1xg9T/qL+cGW9gPrLZH6eJcf8Qh/S3bUmsuk3P+1LuQLhgul7e0Yea/rT8BAAD//wMA UEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPRfVHS wxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2Pb9/ gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf1x+Y nhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1uPnW/QEA AP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90aGVtZU1hbmFn ZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eODN87fFNWbSw1ZLJwH DYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65JGo9 i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABYAAAB0aGVt ZS90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDS SX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwd EiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteX lqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrA Z2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bps QXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ /sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRg Dq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjW DPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+/ /ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb 5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJ iaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQO SUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6 SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrd vsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68G t2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7 XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpk CftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3Z Y2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8 OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCR PuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7j FLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDr RSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF 0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV 9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn 9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7 nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW 9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQ LpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMn UxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQA BgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnht bC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNj Mt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCu OKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAj m6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEAgoq8E/oAAAAcAgAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAA AAAAAAAAAAAAACsBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAA AAAAAAAAAAAAABQCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAh AJa1reKWBgAAUBsAABYAAAAAAAAAAAAAAAAA0QIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAACbCQAAdGhlbWUvdGhlbWUvX3Jl bHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAJYKAAAAADw/eG1sIHZlcnNp b249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4 bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYv bWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFj Y2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2Vu dDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9s SGxpbms9ImZvbEhsaW5rIi8+AAAAABEAAAArAAAAQAAAAFQAAABlAAAAgQAAAIsAAACVAAAArQAA ALAAAAC1AAAAuAAAANEAAADoAAAA9gAAAAcBAAAbAQAALAEAAFABAABkAQAAhAEAAJcBAACoAQAA tAEAALkBAADRAQAA4gEAAPoBAAAXAgAAKAIAAEECAABSAgAAagIAAHICAACAAgAAiAIAAKcCAAAB AAAAAAAAAAAA/////wcEAAAAAAAAAQAAAAAAAAAAAP////8IBAAAAAAAAAEAAAAAAAAAAAD///// CQQAAAAAAAABAAAAAAAAAAAA/////woEAAAAAAAAAQAAAAAAAAAAAP////8MBAAAAAAAAAEAAAAA AAAAAAD/////DgQAAAAAAAABAAAAAAAAAAAA/////w8EAAAAAAAAAQAAAAAAAAAAAP////8VBAAA AAAAAAEAAAAAAAAAAAD/////FwQAAAAAAAABAAAAAAAAAAAA/////xoEAAAAAAAAAQAAAAAAAAAA AP////8bBAAAAAAAAAEAAAAAAAAAAAD/////HAQAAAAAAAABAAAAAAAAAAAA/////yAEAAAAAAAA AQAAAAAAAAAAAP////8hBAAAAAAAAAEAAAAAAAAAAAD/////IgQAAAAAAAABAAAAAAAAAAAA//// /yQEAAAAAAAAAQAAAAAAAAAAAP////8oBAAAAAAAAAEAAAAAAAAAAAD/////KgQAAAAAAAABAAAA AAAAAAAA/////ysEAAAAAAAAAQAAAAAAAAAAAP////8sBAAAAAAAAAEAAAAAAAAAAAD/////LQQA AAAAAAABAAAAAAAAAAAA/////y4EAAAAAAAAAQAAAAAAAAAAAP////8vBAAAAAAAAAEAAAAAAAAA AAD/////MQQAAAAAAAABAAAAAAAAAAAA/////zIEAAAAAAAAAQAAAAAAAAAAAP////83BAAAAAAA AAEAAAAAAAAAAAD/////OQQAAAAAAAABAAAAAAAAAAAA/////zsEAAAAAAAAAQAAAAAAAAAAAP// //88BAAAAAAAAAEAAAAAAAAAAAD/////PgQAAAAAAAABAAAAAAAAAAAA/////0AEAAAAAAAAAQAA AAAAAAAAAP////9DBAAAAAAAAAEAAAAAAAAAAAD/////RQQAAAAAAAABAAAAAAAAAAAA/////0cE AAAAAAAAAQAAAAAAAAAAAP////9JBAAAAAAAAAEAAAAAAAAAAAD/////SgQAAAAAAAABAAAAAAAA AAAA/////wAAAAAAAAAAAAAAABEAAAArAAAAQAAAAFQAAABlAAAAgQAAAIsAAACVAAAArQAAALAA AAC1AAAAuAAAANEAAADoAAAA9gAAAAcBAAAbAQAALAEAAFABAABkAQAAhAEAAJcBAACoAQAAtAEA ALkBAADRAQAA4gEAAPoBAAAXAgAAKAIAAEECAABSAgAAagIAAHICAACAAgAAiAIAAIsCAAAAAAAA AAABAAAAAAACAAAAAAADAAAAAAAEAAAAAAAFAAAAAAAGAAAAAAAHAAAAAAAIAAAAAAAJAAAAAAAK AAAAAAALAAAAAAAMAAAAAAANAAAAAAAOAAAAAAAPAAAAAAAQAAAAAAARAAAAAAASAAAAAAATAAAA AAAUAAAAAAAVAAAAAAAWAAAAAAAXAAAAAAAYAAAAAAAZAAAAAAAaAAAAAAAbAAAAAAAcAAAAAAAd AAAAAAAeAAAAAAAfAAAAAAAgAAAAAAAhAAAAAAAiAAAAAAAjAAAAAAD//wAAAAAAAAAApwIAABQA ABYAAAQA/////wAIAAChCQAApwoAAAYAAAAJAAAAAAgAAAQJAAAWCgAApwoAAAcAAAAIAAAACgAA AAAAAAAYAAAAGwAAAKcCAACTXxT/FZwPAADwOAAAAAAABvAYAAAAAggAAAIAAABKAAAAAQAAAAEA AABLAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvA4IAAAEAAI8AgAAABKAAAASgQAAA8A A/BuGwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAD 8DYbAAAPAATwngAAAAEACfAQAAAAeggAALQLAABWJwAAkDIAAAIACvAIAAAAAgQAAAECAAAzAAvw EgAAAH8AwAHAAYgDAAAAAL8DAAAgAKMAIvE8AAAAjwMAAAAAkAMDAAAAkQMAAAAAkgMDAAAAqgMA AAAAvwMAAgACAAUAAAAAPwUBAAEAwgfv2P//wwfv2P//AAAQ8AQAAAAAAAAAAAAR8AQAAAABAAAA DwAE8FoAAACyBArwCAAAAAMEAAACCgAAUwAL8B4AAAB/AAQABABYAQAAAAB/ARAAEAC/AQEAAQA/ AwAAEAAAAA/wEAAAAHoIAAC0CwAAVicAAJAyAAAAABHwBAAAAAEAAAAPAATwTgAAAAICCvAIAAAA BAQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAqAwAACARAADnFwAAIREA AAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAAFBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAA AwMAAAAAAAAP8BAAAAChDAAAKRMAAOEXAAAqEwAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrwCAAA AAYEAABCCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAPMXAABRIAAAICMAAFIg AAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAABwQAAAIKAABDAAvwGAAAAIAAAAABAIoABwQA AL8BAAAQAP8BAAAIAAAAD/AQAAAA/Q4AAPsOAACtFQAAZBAAAAAAEfAEAAAAAQAAAAAADfAEAAAA AAABAA8ABPBgAAAAogwK8AgAAAAIBAAAAgoAAEMAC/AYAAAAgAAAAAIAigAIBAAAvwEAABAA/wEA AAgAAAAP8BAAAAAyGQAAzRsAAGgiAACuHQAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAIADwAE8GAA AACiDArwCAAAAAkEAAACCgAAQwAL8BgAAACAAAAAAwCKAAkEAAC/AQAAEAD/AQAACAAAAA/wEAAA AI8aAAAaGgAAdyIAALsbAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAAwAPAATwYAAAAKIMCvAIAAAA CgQAAAIKAABDAAvwGAAAAIAAAAAEAIoACgQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAGw8AAPIPAADP FgAAXBEAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAEAA8ABPBOAAAAAgIK8AgAAAALBAAAQgsAADMA C/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAChDAAAIxIAAOEXAAAkEgAAAAAR8AQAAAAB AAAADwAE8GAAAACiDArwCAAAAAwEAAACCgAAQwAL8BgAAACAAAAABQCKAAwEAAC/AQAAEAD/AQAA CAAAAA/wEAAAABsPAAAOEQAAohUAAHcSAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAABQAPAATwTgAA AAICCvAIAAAADQQAAIILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAA/BcAAB4b AAAsIwAAHxsAAAAAEfAEAAAAAQAAAA8ABPBgAAAAogwK8AgAAAAOBAAAAgoAAEMAC/AYAAAAgAAA AAYAigAOBAAAvwEAABAA/wEAAAgAAAAP8BAAAAD7DQAAPSEAAC8YAACnIgAAAAAR8AQAAAABAAAA AAAN8AQAAAAAAAYADwAE8GAAAAASAArwCAAAAA8EAAACCgAAQwAL8BgAAACAAAAABwCKAA8EAACB AfLy8gDOAQYAAAAAAA/wEAAAALAMAABYJgAALyMAAMonAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAA BwAPAATwQgAAAAICCvAIAAAAEAQAAEILAAATAAvwBgAAAAMDAAAAAAAAD/AQAAAAICMAAP4MAAA8 IwAAkDIAAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAARBAAAwgsAADMAC/ASAAAAzgEGAAAA 0QEBAAAAAwMAAAAAAAAP8BAAAAD2FwAAFhwAAC0jAAAXHAAAAAAR8AQAAAABAAAADwAE8E4AAAAC AgrwCAAAABIEAABCCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAPcXAACuMAAA KyMAAK8wAAAAABHwBAAAAAEAAAAPAATwTgAAAAICCvAIAAAAEwQAAAILAAAzAAvwEgAAAM4BBgAA ANEBAQAAAAMDAAAAAAAAD/AQAAAA/BcAAFUhAAAzIwAAViEAAAAAEfAEAAAAAQAAAA8ABPBOAAAA AgIK8AgAAAAUBAAAAgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAACpDAAAMxoA APYXAAA0GgAAAAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAABUEAAACCgAAQwAL8BgAAACAAAAA CACKABUEAAC/AQAAEAD/AQAACAAAAA/wEAAAAAIcAACmLwAAgiEAAEcxAAAAABHwBAAAAAEAAAAA AA3wBAAAAAAACAAPAATwTgAAAAICCvAIAAAAFgQAAEILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMD AAAAAAAAD/AQAAAAsgwAACwXAADyFwAALRcAAAAAEfAEAAAAAQAAAA8ABPBgAAAAogwK8AgAAAAX BAAAAgoAAEMAC/AYAAAAgAAAAAkAigAXBAAAvwEAABAA/wEAAAgAAAAP8BAAAAC9GQAAPh8AAHcj AACnIAAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAkADwAE8EIAAAACAgrwCAAAABgEAAACCwAAEwAL 8AYAAAADAwAAAAAAAA/wEAAAAPIXAAAQDQAA9RcAAJAyAAAAABHwBAAAAAEAAAAPAATwQgAAAAIC CvAIAAAAGQQAAEILAAATAAvwBgAAAAMDAAAAAAAAD/AQAAAAoQwAABANAACyDAAAkDIAAAAAEfAE AAAAAQAAAA8ABPBUAAAAEgAK8AgAAAAaBAAAAgoAACMAC/AMAAAAgAAAAAoAigAaBAAAAAAP8BAA AAB6CAAAtAsAANYQAAAQDQAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAoADwAE8FQAAAASAArwCAAA ABsEAAACCgAAIwAL8AwAAACAAAAACwCKABsEAAAAAA/wEAAAAKYTAAC0CwAAAhwAABANAAAAABHw BAAAAAEAAAAAAA3wBAAAAAAACwAPAATwVAAAABIACvAIAAAAHAQAAAIKAAAjAAvwDAAAAIAAAAAM AIoAHAQAAAAAD/AQAAAA+h4AALQLAABWJwAAEA0AAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAMAA8A BPBOAAAAAgIK8AgAAAAdBAAAggsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAACq DAAAJRYAAPEXAAAoFgAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrwCAAAAB4EAAACCwAAMwAL8BIA AADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAK8MAAAYEAAA8RcAABkQAAAAABHwBAAAAAEAAAAP AATwTgAAAAICCvAIAAAAHwQAAEILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAA rAwAABUPAADsFwAAFg8AAAAAEfAEAAAAAQAAAA8ABPBgAAAAogwK8AgAAAAgBAAAAgoAAEMAC/AY AAAAgAAAAA0AigAgBAAAvwEAABAA/wEAAAgAAAAP8BAAAACFDQAA8g0AAI8WAAA9DwAAAAAR8AQA AAABAAAAAAAN8AQAAAAAAA0ADwAE8GAAAACiDArwCAAAACEEAAACCgAAQwAL8BgAAACAAAAADgCK ACEEAAC/AQAAEAD/AQAACAAAAA/wEAAAAKIOAAAPEgAAhBYAAHgTAAAAABHwBAAAAAEAAAAAAA3w BAAAAAAADgAPAATwYAAAAKIMCvAIAAAAIgQAAAIKAABDAAvwGAAAAIAAAAAPAIoAIgQAAL8BAAAQ AP8BAAAIAAAAD/AQAAAAwQ8AACIZAACtFQAAixoAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAPAA8A BPBOAAAAAgIK8AgAAAAjBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAC8 DAAAYSIAAPwXAABjIgAAAAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAACQEAAACCgAAQwAL8BgA AACAAAAAEACKACQEAAC/AQAAEAD/AQAACAAAAA/wEAAAAEgPAABDIgAAKhYAAK0jAAAAABHwBAAA AAEAAAAAAA3wBAAAAAAAEAAPAATwTgAAAAICCvAIAAAAJQQAAAILAAAzAAvwEgAAAM4BBgAAANEB AQAAAAMDAAAAAAAAD/AQAAAADhgAANMxAAAnIwAA1DEAAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK 8AgAAAAmBAAAAgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAChDAAA0CgAAPYX AADRKAAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrwCAAAACcEAABCCwAAMwAL8BIAAADOAQYAAADR AQEAAAADAwAAAAAAAA/wEAAAAKoMAACdLgAA/hcAAJ4uAAAAABHwBAAAAAEAAAAPAATwYAAAAKIM CvAIAAAAKAQAAAIKAABDAAvwGAAAAIAAAAARAIoAKAQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAGw8A AMInAAB/FgAAKykAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAARAA8ABPBOAAAAAgIK8AgAAAApBAAA QgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAC9DAAADCoAAPEXAAANKgAAAAAR 8AQAAAABAAAADwAE8GAAAACiDArwCAAAACoEAAACCgAAQwAL8BgAAACAAAAAEgCKACoEAAC/AQAA EAD/AQAACAAAAA/wEAAAAGkPAADvKAAAZBYAAFkqAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAEgAP AATwYAAAAKIMCvAIAAAAKwQAAAIKAABDAAvwGAAAAIAAAAATAIoAKwQAAL8BAAAQAP8BAAAIAAAA D/AQAAAAQQwAAO4pAADyGAAAWCsAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAATAA8ABPBgAAAAogwK 8AgAAAAsBAAAAgoAAEMAC/AYAAAAgAAAABQAigAsBAAAvwEAABAA/wEAAAgAAAAP8BAAAACiDgAA bSwAABEWAADXLQAAAAAR8AQAAAABAAAAAAAN8AQAAAAAABQADwAE8GAAAACiDArwCAAAAC0EAAAC CgAAQwAL8BgAAACAAAAAFQCKAC0EAAC/AQAAEAD/AQAACAAAAA/wEAAAAEcNAAARFwAADhgAAHsY AAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAFQAPAATwYAAAAKIMCvAIAAAALgQAAAIKAABDAAvwGAAA AIAAAAAWAIoALgQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAPA8AAAwVAADQFQAAdhYAAAAAEfAEAAAA AQAAAAAADfAEAAAAAAAWAA8ABPBgAAAAogwK8AgAAAAvBAAAAgoAAEMAC/AYAAAAgAAAABcAigAv BAAAvwEAABAA/wEAAAgAAAAP8BAAAABcDwAAGxYAANAVAACEFwAAAAAR8AQAAAABAAAAAAAN8AQA AAAAABcADwAE8E4AAAACAgrwCAAAADAEAABCCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAA AA/wEAAAAKEMAAArGAAA9RcAACwYAAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAAMQQAAAIK AABDAAvwGAAAAIAAAAAYAIoAMQQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAjRsAAOsaAACXIAAAKxwA AAAAEfAEAAAAAQAAAAAADfAEAAAAAAAYAA8ABPBgAAAAogwK8AgAAAAyBAAAAgoAAEMAC/AYAAAA gAAAABkAigAyBAAAvwEAABAA/wEAAAgAAAAP8BAAAAAbHAAAQiAAAPoeAACrIQAAAAAR8AQAAAAB AAAAAAAN8AQAAAAAABkADwAE8E4AAAACAgrwCAAAADMEAAACCwAAMwAL8BIAAADOAQYAAADRAQEA AAADAwAAAAAAAA/wEAAAAKkMAABaIwAA9hcAAFsjAAAAABHwBAAAAAEAAAAPAATwTgAAAAICCvAI AAAANAQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAuQwAAJYvAADzFwAA ly8AAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAA1BAAAwgsAADMAC/ASAAAAzgEGAAAA0QEB AAAAAwMAAAAAAAAP8BAAAAD2FwAAAB0AAC0jAAABHQAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrw CAAAADYEAACCCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAKoMAAApFAAA8RcA ACsUAAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAANwQAAAIKAABDAAvwGAAAAIAAAAAaAIoA NwQAAL8BAAAQAP8BAAAIAAAAD/AQAAAA+w0AABcTAAAkFwAAgBQAAAAAEfAEAAAAAQAAAAAADfAE AAAAAAAaAA8ABPBOAAAAAgIK8AgAAAA4BAAAggsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAA AAAP8BAAAACqDAAAIBUAAPEXAAAjFQAAAAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAADkEAAAC CgAAQwAL8BgAAACAAAAAGwCKADkEAAC/AQAAEAD/AQAACAAAAA/wEAAAAO0OAAALFAAAzxYAAHUV AAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAGwAPAATwTgAAAAICCvAIAAAAOgQAAIILAAAzAAvwEgAA AM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAuQwAADMZAAAAGAAANhkAAAAAEfAEAAAAAQAAAA8A BPBgAAAAogwK8AgAAAA7BAAAAgoAAEMAC/AYAAAAgAAAABwAigA7BAAAvwEAABAA/wEAAAgAAAAP 8BAAAAAKDgAAIRgAADMXAACLGQAAAAAR8AQAAAABAAAAAAAN8AQAAAAAABwADwAE8GAAAACiDArw CAAAADwEAAACCgAAQwAL8BgAAACAAAAAHQCKADwEAAC/AQAAEAD/AQAACAAAAA/wEAAAAPsNAAAI HQAALxgAAHIeAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAHQAPAATwTgAAAAICCvAIAAAAPQQAAEIL AAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAvAwAACweAAD8FwAALh4AAAAAEfAE AAAAAQAAAA8ABPBgAAAAogwK8AgAAAA+BAAAAgoAAEMAC/AYAAAAgAAAAB4AigA+BAAAvwEAABAA /wEAAAgAAAAP8BAAAAB/DwAAEB4AAGEWAAB6HwAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAB4ADwAE 8E4AAAACAgrwCAAAAD8EAAACCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAKkM AAAuHwAA9hcAAC8fAAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAAQAQAAAIKAABDAAvwGAAA AIAAAAAfAIoAQAQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAog4AAD0jAAA2FwAApiQAAAAAEfAEAAAA AQAAAAAADfAEAAAAAAAfAA8ABPBOAAAAAgIK8AgAAABBBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEB AAAAAwMAAAAAAAAP8BAAAAC8DAAAZCQAAPwXAABlJAAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrw CAAAAEIEAAACCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAKkMAAA/JQAA9hcA AEAlAAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAAQwQAAAIKAABDAAvwGAAAAIAAAAAgAIoA QwQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAaQ8AACgkAABLFgAAkSUAAAAAEfAEAAAAAQAAAAAADfAE AAAAAAAgAA8ABPBOAAAAAgIK8AgAAABEBAAAAgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAA AAAP8BAAAACqDAAAXiwAAP8XAABfLAAAAAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAAEUEAAAC CgAAQwAL8BgAAACAAAAAIQCKAEUEAAC/AQAAEAD/AQAACAAAAA/wEAAAAKYNAAApKwAAzxYAAJMs AAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAIQAPAATwTgAAAAICCvAIAAAARgQAAEILAAAzAAvwEgAA AM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAArgwAADcrAAAAGAAAOCsAAAAAEfAEAAAAAQAAAA8A BPBgAAAAogwK8AgAAABHBAAAAgoAAEMAC/AYAAAAgAAAACIAigBHBAAAvwEAABAA/wEAAAgAAAAP 8BAAAACLEAAAdy0AAKYUAAAYLwAAAAAR8AQAAAABAAAAAAAN8AQAAAAAACIADwAE8E4AAAACAgrw CAAAAEgEAAACCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAKEMAAB3LQAA9hcA AHgtAAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAASQQAAAIKAABDAAvwGAAAAIAAAAAjAIoA SQQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAfw8AAHEuAABPFQAA2y8AAAAAEfAEAAAAAQAAAAAADfAE AAAAAAAjAA8ABPB0AAAAogwK8AgAAABKBAAAAgoAAEMAC/AYAAAAgAAAACQAigBKBAAAvwEAABAA /wEAAAgAIwAi8QwAAACqAwAgAA8/BQAAAQAAAA/wEAAAABscAACvMAAAlyAAABgyAAAAABHwBAAA AAEAAAAAAA3wBAAAAAAAJAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsB AAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAD8CBfBgBAAAAQAS8BgAAAABAAAAAAAA AAAAAABIBAAA//////////8BABLwGAAAAAIAAAAAAAAAAAAAADUEAAD//////////wEAEvAYAAAA AwAAAAAAAAAAAAAAJQQAAP//////////AQAS8BgAAAAEAAAAAAAAAAAAAABGBAAA//////////8B ABLwGAAAAAUAAAAAAAAAAAAAACYEAAD//////////wEAEvAYAAAABgAAAAAAAAAAAAAANAQAAP// ////////AQAS8BgAAAAHAAAAAAAAAAAAAAATBAAA//////////8BABLwGAAAAAgAAAAAAAAAAAAA AAUEAAD//////////wEAEvAYAAAACQAAAAAAAAAAAAAAKQQAAP//////////AQAS8BgAAAAKAAAA AAAAAAAAAAAnBAAA//////////8BABLwGAAAAAsAAAAAAAAAAAAAACMEAAD//////////wEAEvAY AAAADAAAAAAAAAAAAAAAEAQAAP//////////AQAS8BgAAAANAAAAAAAAAAAAAAAzBAAA//////// //8BABLwGAAAAA4AAAAAAAAAAAAAAD0EAAD//////////wEAEvAYAAAADwAAAAAAAAAAAAAAFAQA AP//////////AQAS8BgAAAAQAAAAAAAAAAAAAAAEBAAA//////////8BABLwGAAAABEAAAAAAAAA AAAAAB0EAAD//////////wEAEvAYAAAAEgAAAAAAAAAAAAAAPwQAAP//////////AQAS8BgAAAAT AAAAAAAAAAAAAAAwBAAA//////////8BABLwGAAAABQAAAAAAAAAAAAAADoEAAD//////////wEA EvAYAAAAFQAAAAAAAAAAAAAADQQAAP//////////AQAS8BgAAAAWAAAAAAAAAAAAAAAYBAAA//// //////8BABLwGAAAABcAAAAAAAAAAAAAABEEAAD//////////wEAEvAYAAAAGAAAAAAAAAAAAAAA OAQAAP//////////AQAS8BgAAAAZAAAAAAAAAAAAAABCBAAA//////////8BABLwGAAAABoAAAAA AAAAAAAAABIEAAD//////////wEAEvAYAAAAGwAAAAAAAAAAAAAAQQQAAP//////////AQAS8BgA AAAcAAAAAAAAAAAAAAAfBAAA//////////8BABLwGAAAAB0AAAAAAAAAAAAAABkEAAD///////// /wEAEvAYAAAAHgAAAAAAAAAAAAAAHgQAAP//////////AQAS8BgAAAAfAAAAAAAAAAAAAABEBAAA //////////8BABLwGAAAACAAAAAAAAAAAAAAADYEAAD//////////wEAEvAYAAAAIQAAAAAAAAAA AAAACwQAAP//////////AQAS8BgAAAAiAAAAAAAAAAAAAAAWBAAA//////////8BABLwGAAAACMA AAAAAAAAAAAAAAYEAAD//////////xkAAACnAgAAAgQAAAAAAAAAAAAA3B4AANwmAAB0gAAAAAAA AAAAHQAAAGQAAABrAAAAigAAAJcAAADlAAAA7AAAAPYAAAD+AAAAKwEAADEBAABJAQAAUgEAAG0B AAB2AQAA1gEAAOwBAAD/AQAAFQIAAB8CAAAoAgAAbwIAAIUCAACoAgAABwAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAAB0AAACOAAAAlwAAACMCAAAoAgAA TQIAAFQCAACoAgAABwAHADMABwAzAAcAMwAHAAIAAAAEAAAACAAAAOUAAAAAAAAAAQAAAFQ3QADr am4AAAAAAB0AAAAfAAAAAAAAAAEAAAD/QAGAAQAcAAAAHAAAAAA40AQBAAEAHAAAAAAAAAAcAAAA AAAAAAIQAAAAAAAAAKcCAACgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAA AAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAFAAAARx6QAQAAAgIGAwUEBQID BIcqACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA NR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMy6Q AQAAAgsGBAICAgICBIcqACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADcukAEAAAIP BQICAgQDAgTvAgCgeyAAQAAAAAAAAAAAnwAAAAAAAABDAGEAbABpAGIAcgBpAAAAQR6QAQAAAgQF AwUEBgMCBO8CAKDrIABCAAAAAAAAAACfAAAAAAAAAEMAYQBtAGIAcgBpAGEAIABNAGEAdABoAAAA IgAEAHEIiBgA8NACAABoAQAAAAAwUMGGNVDBhgAAAAABAAEAAAAEAAAAGQAAAAEAAQAAAAQAA5AB AAAAZQAAAEACAAABAAEAAAAEAAAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKAFoAW0ALQAgYEyMAAAAAAAAAAAAAAAAAAAHAAAAKQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACDKDUQDwEAAI APz9AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhIUAAAAAAJ8P8PAQgkUAAA5AQAAP///3////9/ ////f////3////9/////f////39UN0AAAAQAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAhBAAAAAAA AAAAAAAAAAAAAAAAABAcAAAEAAAAAAAAAAAAeAAAAHgAAAAAAAAAAAAAAKAFAAD//xIAAAAAAAAA AAAAAAAAAAATAEoAYQB0AGkAIABLAGEAbABpAG4AZwBnAGEAIABQAHIAYQBqAGEAEwBKAGEAdABp ACAASwBhAGwAaQBuAGcAZwBhACAAUAByAGEAagBhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIABAAAR AAAAAQAAAJAAAAACAAAAmAAAAAMAAACkAAAABAAAALAAAAAFAAAAzAAAAAYAAADYAAAABwAAAOQA AAAIAAAA9AAAAAkAAAAQAQAAEgAAABwBAAAKAAAAPAEAAAwAAABIAQAADQAAAFQBAAAOAAAAYAEA AA8AAABoAQAAEAAAAHABAAATAAAAeAEAAAIAAADkBAAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAABQAAABKYXRpIEthbGluZ2dhIFByYWphAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAI AAAATm9ybWFsAAAeAAAAFAAAAEphdGkgS2FsaW5nZ2EgUHJhamEAHgAAAAQAAAAxAAAAHgAAABgA AABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQAAABAAAAAAEbDIwAAAABAAAAAAMhsxudSyAFAAAAAACY9 eehSyAEDAAAAAQAAAAMAAAAEAAAAAwAAABkAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAD0AAAADAAAAAEAAABo AAAADwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAA AAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAA1QAAAAIAAADkBAAAHgAAABAAAABLYWxpbmdn YSBDb3JwAAAAAwAAAAEAAAADAAAAAQAAAAMAAAAcAAAAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAD+////DQAAAA4AAAAPAAAAEAAAABEAAAAS AAAAEwAAAP7///8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAA AAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAA AC8AAAAwAAAAMQAAADIAAAAzAAAA/v///zUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAD+//// PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAP7////9////RgAAAP7////+/////v////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////9SAG8AbwB0ACAARQBu AHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACwpUqb6FLIAUgAAACAAAAAAAAA AEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADAAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAUAAAA2T4AAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuFgAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAAAAQAAAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA8AAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIA AAAAAMAAAAAAAABGJwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCA5Ny0yMDAzIERvY3VtZW50AAoA AABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_Part_10989_26389566.1199905229342 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_Part_10989_26389566.1199905229342-- From sip-bounces@ietf.org Wed Jan 09 14:16:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgP2-0003OM-Kf; Wed, 09 Jan 2008 14:15:52 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCgP0-0003Nu-M5 for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 14:15:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgP0-0003Nh-Bw for sip@ietf.org; Wed, 09 Jan 2008 14:15:50 -0500 Received: from fg-out-1718.google.com ([72.14.220.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCgOz-00006J-9A for sip@ietf.org; Wed, 09 Jan 2008 14:15:50 -0500 Received: by fg-out-1718.google.com with SMTP id 16so365854fgg.41 for ; Wed, 09 Jan 2008 11:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=S718QlKTwTzasydvvwzdTtzsuRuhAVJzdlSX0gHHOF8=; b=HaJ2UWtE8DI/thunYkXwWfEyjTf33Io4/j88eogvcc3dl9ysRW5aC8sts25RSLUcBpXN0by+BhM7K9ADKYbaLNd5RJg+hOf2hcoxAWJRIoxewXcWwo6hpI2loV3cgdHYwBeJpB5Dl+reC8Lx6EaU2TM0DAeenAhVZ8QUZzDoYyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=SGUOMeHJ/nLCZ5m7Dk/IyhAZWjiKzButyog85VBP+UmrycPUqX9KxaxQwiT+tO8X9woLpK5SG7rEpZLv0sPjKN6mrbHF6GTemja0tIESSOwYv8Dl7OgT9JuQcIbQIxbqwndMnKsWCujsHzTCVntGg6AF0vxVDSQPOgzCy3z7tNU= Received: by 10.86.89.4 with SMTP id m4mr973406fgb.12.1199906146367; Wed, 09 Jan 2008 11:15:46 -0800 (PST) Received: by 10.86.61.5 with HTTP; Wed, 9 Jan 2008 11:15:46 -0800 (PST) Message-ID: Date: Thu, 10 Jan 2008 02:15:46 +0700 From: "Jati Kalingga Praja" To: sip@ietf.org, megaco@ietf.org, sip-implementors@lists.cs.columbia.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11016_23566565.1199906146345" X-Spam-Score: 0.3 (/) X-Scan-Signature: bf298c52ab1dc9f39fd87b679918f163 Cc: Subject: [Sip] Translation SIP 2 Megaco X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ------=_Part_11016_23566565.1199906146345 Content-Type: multipart/alternative; boundary="----=_Part_11017_22392205.1199906146346" ------=_Part_11017_22392205.1199906146346 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have another translation questions again,, I attached the file too. Or you can download it in : http://www.4shared.com/file/34360429/6e0d5471/sip2megaco_interworking.html. If i want to count delay translation from Megaco message to "180 Ringing", which megaco message do i use?Is *modify (signal:{cg/bt})*?or modify response?or add response? Thx before in advance, Best Regards, Jati ------=_Part_11017_22392205.1199906146346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I have another translation questions again,,
I attached the file too. Or you can download it in : http://www.4shared.com/file/34360429/6e0d5471/sip2megaco_interworking.html .

If i want to count delay translation from Megaco message to "180 Ringing", which megaco message do i use?Is modify (signal:{cg/bt})?or modify response?or add response?

Thx before in advance,

Best Regards,

Jati
------=_Part_11017_22392205.1199906146346-- ------=_Part_11016_23566565.1199906146345 Content-Type: application/msword; name="sip2megaco interworking.doc" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fb88ypga0 Content-Disposition: attachment; filename="sip2megaco interworking.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARAAAAAAAAAAA EAAARgAAAAEAAAD+////AAAAAEMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAeYAJBAAA+BK/AAAAAAAAEAAAAAAACAAAYQoAAA4AYmpiakXqReoAAAAAAAAAAAAAAAAAAAAA AAAJBBYALhYAACeAAAAngAAAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwIAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAJgFAAAAAAAAmAUAANsS AAAAAAAA2xIAAAAAAADPFwAAAAAAAM8XAAAAAAAAzxcAABQAAAAAAAAAAAAAAP////8AAAAA4xcA AAAAAADjFwAAAAAAAOMXAAAAAAAA4xcAABQAAAD3FwAAHAAAAOMXAAAAAAAA1TgAADABAAATGAAA FgAAACkYAAAAAAAAKRgAAAAAAAApGAAAAAAAACkYAAAAAAAATDcAAAAAAABMNwAAAAAAAEw3AAAA AAAAVDgAAAIAAABWOAAAAAAAAFY4AAAAAAAAVjgAAAAAAABWOAAAAAAAAFY4AAAAAAAAVjgAACQA AAAFOgAAogIAAKc8AAB2AAAAejgAABUAAAAAAAAAAAAAAAAAAAAAAAAAzxcAAAAAAABMNwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAqNwAAIgAAAEw3AAAAAAAATDcAAAAAAABMNwAAAAAAAHo4AAAAAAAA AAAAAAAAAADbEgAAAAAAANsSAAAAAAAAKRgAAAAAAAAAAAAAAAAAACkYAAABHwAAjzgAABYAAAAg OAAAAAAAACA4AAAAAAAAIDgAAAAAAABMNwAAiAAAANsSAACSAwAAKRgAAAAAAADPFwAAAAAAACkY AAAAAAAAVDgAAAAAAAAAAAAAAAAAACA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAATDcAAAAAAABUOAAAAAAAAAAAAAAAAAAAIDgAAAAAAAAAAAAA AAAAACA4AAAAAAAAbRYAAGIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIDgAAAAAAAApGAAAAAAAAP////8AAAAA0FE1o+hS yAEAAAAAAAAAAOMXAAAAAAAA1DcAAEwAAAAgOAAAAAAAAAAAAAAAAAAAQDgAABQAAAClOAAAMAAA ANU4AAAAAAAAIDgAAAAAAAAdPQAAAAAAACA4AAAAAAAAHT0AAAAAAAAgOAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAB09AAAAAAAAAAAAAAAAAADPFwAAAAAAACA4AAAgAAAATDcAAAAAAABMNwAAAAAAACA4 AAAAAAAATDcAAAAAAABMNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATDcA AAAAAABMNwAAAAAAAEw3AAAAAAAAejgAAAAAAAB6OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEw3AAAA AAAATDcAAAAAAABMNwAAAAAAANU4AAAAAAAATDcAAAAAAABMNwAAAAAAAEw3AAAAAAAATDcAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAB09AAAAAAAATDcAAAAAAABM NwAAAAAAAEw3AAAAAAAATDcAAAAAAABMNwAAAAAAAEw3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMNwAAAAAAAEw3AAAAAAAATDcA AAAAAACYBQAACQwAAKERAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMgU0hB UEUgIFwqIE1FUkdFRk9STUFUIBQIARUNTW9kaWZ5IFJlc3BvbnNlDQ0xODAgUmluZ2luZyAoNCkN DVJlcXVlc3Q6IElOVklURSAoMSkNDU5vdGlmeSBPZmZob29rICg1KQ0NTm90aWZ5IFJlc3BvbnNl DQ1Nb2RpZnkgKG1vZGU6c2VuZHJlY3YpICg2KQ0NUlRQICg5KQ0NQllFICgxMCkNDTIwMCBPSw0N MjAwIE9LIFNEUCAgKDcpDQ1BDQ1NR0MNDUINDU1vZGlmeSB0byBjaGVjayBvZmZob29rDQ1BZGQg KCQsIHRlcm0gcC8xLCBFcGggcC8xKSAoMikNDUFkZCBSZXNwb25zZQ0NTW9kaWZ5IFJlc3BvbnNl DQ1Nb2RpZnkgKHNpZ25hbDp7YWwvcml9KSAoMykNDU1vZGlmeSBSZXNwb25zZQ0NTW9kaWZ5DQ1U cmFuc2FjdGlvbiBSZXNwb25zZSBBY2sNDU1vZGlmeSBSZXNwb25zZQ0NTW9kaWZ5IChzaWduYWw6 eyB9KSAoOCkNDU1vZGlmeSBSZXNwb25zZQ0NQUNLDQ1Nb2RpZnkgKHNpZ25hbDp7Y2cvYnR9KSAo MTEpDQ1Nb2RpZnkgUmVzcG9uc2UNDU5vdGlmeSBPbmhvb2sgKDEyKQ0NU3Vic3RyYWN0ICgxMykN DVRyYW5zYWN0aW9uIFJlc3BvbnNlIEFjaw0NU3Vic3RyYWN0IFJlc3BvbnNlDQ1Ob3RpZnkgUmVz cG9uc2UNDU1vZGlmeQ0NTW9kaWZ5IFJlc3BvbnNlDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAQgA ABgIAAAcCAAAHQgAAC0IAAA/CAAATggAAFIIAABTCAAAVAgAAGIIAABmCAAAZwgAAGgIAAB3CAAA eAgAAHkIAACTCAAAlAgAAJ4IAAChCAAApggAAKcIAACoCAAArwgAALAIAAC+CAAAwAgAAMEIAADD CAAAxAgAAMgIAADJCAAAyggAAMsIAADMCAAA5AgAAOUIAAADCQAABAkAAAUJAAAICQAAEgkAABMJ AAAiCQAAIwkAACQJAAArCQAAPwkAAEAJAABBCQAAUQkAAFIJAABYCQAAWQkAAFoJAAByCQAAcwkA AHQJAACDCQAAhAkAAIUJAACMCQAAnAkAAJ0JAACeCQAArgkAAK8JAACzCQAAtAkAALsJAADQCQAA 9/P38+rz6uTq89vk2/Pk0vPk0vPJ5MnzwPPk0vPJ88nz5Mnz6vPk6vPk6vPk0vPq5Orz6vPk0vPk 0vPk0vPq5Orz6vO38+rkAAAQFWj2MiIAFmgHbPsAQ0oUAAAQFWh4fBUAFmgHbPsAQ0oUAAAQFWgx eAIAFmgHbPsAQ0oUAAAQFWhbWuQAFmgHbPsAQ0oUAAAQFWjFJM0AFmgHbPsAQ0oUAAAKFmgHbPsA Q0oUAAAQFWhTE54AFmgHbPsAQ0oUAAAGFmgHbPsAAA8DagAAAAAWaAds+wBVCAEASAAIAAAdCAAA LQgAAC4IAAA+CAAAPwgAAFMIAABUCAAAZwgAAGgIAAB4CAAAeQgAAJQIAACVCAAAnQgAAJ4IAACn CAAAqAgAAK8IAACwCAAAwAgAAMEIAADDCAAAxAgAAMgIAADJCAAAywgAAMwIAADkCAAA/QAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPAAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAAAHAAADJAFhJAFnZAds+wAABAAAZ2QHbPsAAAEAAAAc5AgAAOUIAAAE CQAABQkAABIJAAATCQAAIwkAACQJAABACQAAQQkAAFEJAABSCQAAWQkAAFoJAABzCQAAdAkAAIQJ AACFCQAAnQkAAJ4JAACuCQAArwkAALMJAAC0CQAA0QkAANIJAADiCQAA4wkAAPYJAAD9AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZAds+wAAAQAAABzQCQAA0QkAANIJ AADiCQAA4wkAAOwJAADwCQAA9QkAAPYJAAD3CQAABQoAAAYKAAAHCgAAHwoAACAKAAAhCgAAMwoA ADQKAAA1CgAARAoAAEUKAABGCgAATAoAAE0KAABOCgAAXQoAAF4KAABfCgAAYAoAAGEKAAD38/fz 7eTt5PPt2/Pt2/Pt2/Pt2/Pt2/Pt2/PX8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABhZoLSrSAAAQFWhbWuQAFmgHbPsAQ0oUAAAQFWjFJM0AFmgH bPsAQ0oUAAAKFmgHbPsAQ0oUAAAGFmgHbPsAABAVaFMTngAWaAds+wBDShQAHfYJAAD3CQAABgoA AAcKAAAgCgAAIQoAADQKAAA1CgAARQoAAEYKAABNCgAATgoAAF4KAABfCgAAYAoAAGEKAAD9AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2QHbPsAAAEAAAAPLAAxkGgBH7DQLyCw 4D0hsKAFIrCgBSOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAARABkAAAAAAAA AAIAAAAAAAAAAAAAAAAAcCFdKugDqAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A BPBEAAAAsgQK8AgAAAABBAAAAAoAADMAC/ASAAAAfwBAAUABAAEQAP//AQHw/wAAEwAi8QYAAAA/ BQEAAQAAABDwBAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagQPABIAAQALAQ8ABwADAAMAAwAA AAQACAAAAJgAAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAAD4CAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAACoAAAANgYAADYGAAAWAAAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAC4AAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAAaAEAAEgBAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALADAAA2BgAA MgYAABgAAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACA BAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAADIGAAAoAgAA2AEAAOgBAAAgBAAAMAQAAEAE AABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQA AFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQ BAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQA AGAEAABwBAAAgAQAAJAEAAA4AQAAWAEAAPgBAAAIAgAAGAIAAFYCAAB+AgAAIAAAAE9KAwBQSgMA UUoDAF9IAQRtSAkEbkgJBHNICQR0SAkEAAAAAFAAAGDx/wIAUAAMEAAAB2z7AAAABgBOAG8AcgBt AGEAbAAAAAIAAAAoAENKGABPSgAAUEoAAFFKAABeSgAAX0gBBGFKGABtSAkEc0gJBHRICQQAAAAA AAAAAAAAAAAAAAAAAABEAEFg8v+hAEQADA0AAAAAAAAQABYARABlAGYAYQB1AGwAdAAgAFAAYQBy AGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/swBSAAwdAAAAAAAAMAYMAFQAYQBiAGwA ZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABr IPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAAFBLAwQUAAYACAAAACEA goq8E/oAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil2M6i SXd9LNIPGOSxLWqPhDQJyd937LhQuggtdCMQYs6Ze1Wuj+OgDhiT81TpVV5ohWR946ir9PvuKbvX KjFQA4MnrPQJk17X11fl7hQwKZmmVOmeOTwYk2yPI6TcByR5aX0cgeUaOxPAfkCH5rYo7oz1xEic 8cTQdfkqC0TXoHqDyC8wisewoPD7+QwkgJgLWKvHM2FaotIQwuAssEQwB2p+6DPfts5i4+1+FGk+ gxfYzQQzv1xg9T/qL+cGW9gPrLZH6eJcf8Qh/S3bUmsuk3P+1LuQLhgul7e0Yea/rT8BAAD//wMA UEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPRfVHS wxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2Pb9/ gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf1x+Y nhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1uPnW/QEA AP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90aGVtZU1hbmFn ZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eODN87fFNWbSw1ZLJwH DYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65JGo9 i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABYAAAB0aGVt ZS90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDS SX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwd EiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteX lqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrA Z2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bps QXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ /sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRg Dq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjW DPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+/ /ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb 5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJ iaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQO SUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6 SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrd vsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68G t2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7 XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpk CftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3Z Y2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8 OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCR PuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7j FLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDr RSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF 0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV 9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn 9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7 nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW 9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQ LpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMn UxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQA BgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnht bC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNj Mt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCu OKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAj m6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEAgoq8E/oAAAAcAgAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAA AAAAAAAAAAAAACsBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAA AAAAAAAAAAAAABQCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAh AJa1reKWBgAAUBsAABYAAAAAAAAAAAAAAAAA0QIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAACbCQAAdGhlbWUvdGhlbWUvX3Jl bHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAJYKAAAAADw/eG1sIHZlcnNp b249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4 bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYv bWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFj Y2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2Vu dDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9s SGxpbms9ImZvbEhsaW5rIi8+AAAAABEAAAAiAAAANwAAAEsAAABcAAAAeAAAAIEAAACLAAAAkwAA AKQAAACnAAAArAAAAK8AAADIAAAA6AAAAPYAAAAHAQAAJAEAADUBAAA9AQAAVwEAAGgBAACBAQAA kgEAAJcBAAC1AQAAxgEAANoBAADqAQAABAIAABgCAAApAgAAMQIAAEICAABhAgAAAQAAAAAAAAAA AP////8HBAAAAAAAAAEAAAAAAAAAAAD/////CAQAAAAAAAABAAAAAAAAAAAA/////wkEAAAAAAAA AQAAAAAAAAAAAP////8KBAAAAAAAAAEAAAAAAAAAAAD/////DAQAAAAAAAABAAAAAAAAAAAA//// /w4EAAAAAAAAAQAAAAAAAAAAAP////8PBAAAAAAAAAEAAAAAAAAAAAD/////FQQAAAAAAAABAAAA AAAAAAAA/////xYEAAAAAAAAAQAAAAAAAAAAAP////8YBAAAAAAAAAEAAAAAAAAAAAD/////HAQA AAAAAAABAAAAAAAAAAAA/////x0EAAAAAAAAAQAAAAAAAAAAAP////8eBAAAAAAAAAEAAAAAAAAA AAD/////IgQAAAAAAAABAAAAAAAAAAAA/////yMEAAAAAAAAAQAAAAAAAAAAAP////8kBAAAAAAA AAEAAAAAAAAAAAD/////JgQAAAAAAAABAAAAAAAAAAAA/////ykEAAAAAAAAAQAAAAAAAAAAAP// //8qBAAAAAAAAAEAAAAAAAAAAAD/////LQQAAAAAAAABAAAAAAAAAAAA/////y4EAAAAAAAAAQAA AAAAAAAAAP////8wBAAAAAAAAAEAAAAAAAAAAAD/////MwQAAAAAAAABAAAAAAAAAAAA/////zQE AAAAAAAAAQAAAAAAAAAAAP////82BAAAAAAAAAEAAAAAAAAAAAD/////NwQAAAAAAAABAAAAAAAA AAAA/////zgEAAAAAAAAAQAAAAAAAAAAAP////86BAAAAAAAAAEAAAAAAAAAAAD/////PQQAAAAA AAABAAAAAAAAAAAA/////z8EAAAAAAAAAQAAAAAAAAAAAP////9BBAAAAAAAAAEAAAAAAAAAAAD/ ////QgQAAAAAAAABAAAAAAAAAAAA/////0MEAAAAAAAAAQAAAAAAAAAAAP////9GBAAAAAAAAAEA AAAAAAAAAAD/////AAAAAAAAAAAAAAAAEQAAACIAAAA3AAAASwAAAFwAAAB4AAAAgQAAAIsAAACT AAAApAAAAKcAAACsAAAArwAAAMgAAADoAAAA9gAAAAcBAAAkAQAANQEAAD0BAABXAQAAaAEAAIEB AACSAQAAlwEAALUBAADGAQAA2gEAAOoBAAAEAgAAGAIAACkCAAAxAgAAQgIAAEUCAAAAAAAAAAAB AAAAAAACAAAAAAADAAAAAAAEAAAAAAAFAAAAAAAGAAAAAAAHAAAAAAAIAAAAAAAJAAAAAAAKAAAA AAALAAAAAAAMAAAAAAANAAAAAAAOAAAAAAAPAAAAAAAQAAAAAAARAAAAAAASAAAAAAATAAAAAAAU AAAAAAAVAAAAAAAWAAAAAAAXAAAAAAAYAAAAAAAZAAAAAAAaAAAAAAAbAAAAAAAcAAAAAAAdAAAA AAAeAAAAAAAfAAAAAAAgAAAAAAAhAAAAAAD//wAAAAAAAAAAYQIAABUAABYAAAQA/////wAIAADQ CQAAYQoAAAYAAAAJAAAAAAgAAOQIAAD2CQAAYQoAAAcAAAAIAAAACgAAAAAAAAAYAAAAGwAAAGEC AACTXxT/FZwPAADwOAAAAAAABvAYAAAAAggAAAIAAABGAAAAAQAAAAEAAABHAAAAQAAe8RAAAAD/ /wAAAAD/AICAgAD3AAAQAA8AAvC4HgAAEAAI8AgAAABGAAAARgQAAA8AA/AuGgAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAD8PYZAAAPAATwngAAAAEA CfAQAAAAoAUAAOQHAAAQJwAAjy8AAAIACvAIAAAAAgQAAAECAAAzAAvwEgAAAH8AwAHAAYgDAAAA AL8DAAAgAKMAIvE8AAAAjwMAAAAAkAMDAAAAkQMAAAAAkgMDAAAAqgMAAAAAvwMAAgACAAUAAAAA PwUBAAEAwgfv2P//wwfv2P//AAAQ8AQAAAAAAAAAAAAR8AQAAAABAAAADwAE8FoAAACyBArwCAAA AAMEAAACCgAAUwAL8B4AAAB/AAQABABYAQAAAAB/ARAAEAC/AQEAAQA/AwAAEAAAAA/wEAAAAKAF AADkBwAAECcAAI8vAAAAABHwBAAAAAEAAAAPAATwTgAAAAICCvAIAAAABAQAAAILAAAzAAvwEgAA AM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAZRYAAFsOAAC4IQAAXA4AAAAAEfAEAAAAAQAAAA8A BPBOAAAAAgIK8AgAAAAFBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAAy CwAA/RIAAHIWAAD+EgAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrwCAAAAAYEAABCCwAAMwAL8BIA AADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAGwWAACHDwAArCEAAIgPAAAAABHwBAAAAAEAAAAP AATwYAAAAKIMCvAIAAAABwQAAAIKAABDAAvwGAAAAIAAAAABAIoABwQAAL8BAAAQAP8BAAAIAAAA D/AQAAAABxkAAOMKAAC3HwAAgwwAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAABAA8ABPBgAAAAogwK 8AgAAAAIBAAAAgoAAEMAC/AYAAAAgAAAAAIAigAIBAAAvwEAABAA/wEAAAgAAAAP8BAAAABDDQAA yxEAANIUAAA8EwAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAIADwAE8GAAAACiDArwCAAAAAkEAAAC CgAAQwAL8BgAAACAAAAAAwCKAAkEAAC/AQAAEAD/AQAACAAAAA/wEAAAAJ4MAAD8CwAA0hQAANwN AAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAAwAPAATwYAAAAKIMCvAIAAAACgQAAAIKAABDAAvwGAAA AIAAAAAEAIoACgQAAL8BAAAQAP8BAAAIAAAAD/AQAAAAQxkAAN4SAACWIAAAfhQAAAAAEfAEAAAA AQAAAAAADfAEAAAAAAAEAA8ABPBOAAAAAgIK8AgAAAALBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEB AAAAAwMAAAAAAAAP8BAAAABpFgAAKRQAAKkhAAArFAAAAAAR8AQAAAABAAAADwAE8GAAAACiDArw CAAAAAwEAAACCgAAQwAL8BgAAACAAAAABQCKAAwEAAC/AQAAEAD/AQAACAAAAA/wEAAAAEMZAAAd FAAAtx8AAL0VAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAABQAPAATwTgAAAAICCvAIAAAADQQAAAIL AAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAchYAAFUVAACiIQAAVhUAAAAAEfAE AAAAAQAAAA8ABPBgAAAAogwK8AgAAAAOBAAAAgoAAEMAC/AYAAAAgAAAAAYAigAOBAAAvwEAABAA /wEAAAgAAAAP8BAAAABbFwAAdRgAAKshAAAVGgAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAYADwAE 8GAAAAASAArwCAAAAA8EAAACCgAAQwAL8BgAAACAAAAABwCKAA8EAACBAfLy8gDOAQYAAAAAAA/w EAAAACgLAAAcIAAApyEAAMUhAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAABwAPAATwQgAAAAICCvAI AAAAEAQAAEILAAATAAvwBgAAAAMDAAAAAAAAD/AQAAAAnCEAAGAJAAC2IQAAjy8AAAAAEfAEAAAA AQAAAA8ABPBOAAAAAgIK8AgAAAARBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP 8BAAAAA4CwAAziMAAFwWAADPIwAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrwCAAAABIEAABCCwAA MwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAH8WAADeJQAAoiEAAN8lAAAAABHwBAAA AAEAAAAPAATwTgAAAAICCvAIAAAAEwQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAA D/AQAAAANAsAANMiAABnFgAA1CIAAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAAUBAAAAgsA ADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAABrFgAAzCQAAKIhAADNJAAAAAAR8AQA AAABAAAADwAE8GAAAACiDArwCAAAABUEAAACCgAAQwAL8BgAAACAAAAACACKABUEAAC/AQAAEAD/ AQAACAAAAA/wEAAAAMcOAAC2IQAAYBMAADkjAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAACAAPAATw YAAAAKIMCvAIAAAAFgQAAAIKAABDAAvwGAAAAIAAAAAJAIoAFgQAAL8BAAAQAP8BAAAIAAAAD/AQ AAAAxw4AAKEiAADEEwAAQSQAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAJAA8ABPBOAAAAAgIK8AgA AAAXBAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAApCwAAwBoAAGkWAADB GgAAAAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAABgEAAACCgAAQwAL8BgAAACAAAAACgCKABgE AAC/AQAAEAD/AQAACAAAAA/wEAAAAIMNAAB5GQAASxQAABkbAAAAABHwBAAAAAEAAAAAAA3wBAAA AAAACgAPAATwTgAAAAICCvAIAAAAGQQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAA D/AQAAAAZRYAAK4ZAAClIQAArxkAAAAAEfAEAAAAAQAAAA8ABPBCAAAAAgIK8AgAAAAaBAAAQgsA ABMAC/AGAAAAAwMAAAAAAAAP8BAAAABHFgAAdAkAAGwWAACPLwAAAAAR8AQAAAABAAAADwAE8EIA AAACAgrwCAAAABsEAAACCwAAEwAL8AYAAAADAwAAAAAAAA/wEAAAACwLAAB0CQAAOAsAAI8vAAAA ABHwBAAAAAEAAAAPAATwVAAAABIACvAIAAAAHAQAAAIKAAAjAAvwDAAAAIAAAAALAIoAHAQAAAAA D/AQAAAA9AYAAOQHAABQDwAAdAkAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAALAA8ABPBUAAAAEgAK 8AgAAAAdBAAAAgoAACMAC/AMAAAAgAAAAAwAigAdBAAAAAAP8BAAAAAgEgAA5AcAAHwaAAB0CQAA AAAR8AQAAAABAAAAAAAN8AQAAAAAAAwADwAE8FQAAAASAArwCAAAAB4EAAACCgAAIwAL8AwAAACA AAAADQCKAB4EAAAAAA/wEAAAAHQdAADkBwAA0CUAAHQJAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAA DQAPAATwTgAAAAICCvAIAAAAHwQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQ AAAALwsAAD0NAABvFgAAPg0AAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAAgBAAAAgsAADMA C/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAABpFgAALwsAALUhAAAwCwAAAAAR8AQAAAAB AAAADwAE8E4AAAACAgrwCAAAACEEAABCCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/w EAAAAGkWAAAwDAAAtSEAADEMAAAAABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAAIgQAAAIKAABD AAvwGAAAAIAAAAAOAIoAIgQAAL8BAAAQAP8BAAAIAAAAD/AQAAAA/BcAAPEJAAAGIQAAbwsAAAAA EfAEAAAAAQAAAAAADfAEAAAAAAAOAA8ABPBgAAAAogwK8AgAAAAjBAAAAgoAAEMAC/AYAAAAgAAA AA8AigAjBAAAvwEAABAA/wEAAAgAAAAP8BAAAAD6FgAABQ0AANEhAAClDgAAAAAR8AQAAAABAAAA AAAN8AQAAAAAAA8ADwAE8GAAAACiDArwCAAAACQEAAACCgAAQwAL8BgAAACAAAAAEACKACQEAAC/ AQAAEAD/AQAACAAAAA/wEAAAAEMZAAA9DgAALx8AAN0PAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAA EAAPAATwTgAAAAICCvAIAAAAJQQAAMILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQ AAAAZRYAAMkbAACvIQAAzRsAAAAAEfAEAAAAAQAAAA8ABPBgAAAAogwK8AgAAAAmBAAAAgoAAEMA C/AYAAAAgAAAABEAigAmBAAAvwEAABAA/wEAAAgAAAAP8BAAAAABGQAAaxcAAOMfAAALGQAAAAAR 8AQAAAABAAAAAAAN8AQAAAAAABEADwAE8E4AAAACAgrwCAAAACcEAAACCwAAMwAL8BIAAADOAQYA AADRAQEAAAADAwAAAAAAAA/wEAAAAGcWAACkEAAAsyEAAKUQAAAAABHwBAAAAAEAAAAPAATwTgAA AAICCvAIAAAAKAQAAEILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQAAAAaRYAANAR AAC1IQAA0REAAAAAEfAEAAAAAQAAAA8ABPBgAAAAogwK8AgAAAApBAAAAgoAAEMAC/AYAAAAgAAA ABIAigApBAAAvwEAABAA/wEAAAgAAAAP8BAAAAC9FwAAZA8AALohAADiEAAAAAAR8AQAAAABAAAA AAAN8AQAAAAAABIADwAE8GAAAACiDArwCAAAACoEAAACCgAAQwAL8BgAAACAAAAAEwCKACoEAAC/ AQAAEAD/AQAACAAAAA/wEAAAAK0YAABlEAAAXR8AAAUSAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAA EwAPAATwTgAAAAICCvAIAAAAKwQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQ AAAAchYAAHIWAACiIQAAcxYAAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAAsBAAAQgsAADMA C/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAABpFgAAjxcAAKkhAACRFwAAAAAR8AQAAAAB AAAADwAE8GAAAACiDArwCAAAAC0EAAACCgAAQwAL8BgAAACAAAAAFACKAC0EAAC/AQAAEAD/AQAA CAAAAA/wEAAAAEIaAAA8FQAAgB8AANwWAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAFAAPAATwYAAA AKIMCvAIAAAALgQAAAIKAABDAAvwGAAAAIAAAAAVAIoALgQAAL8BAAAQAP8BAAAIAAAAD/AQAAAA lhcAAF0WAACGIQAA/RcAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAVAA8ABPBOAAAAAgIK8AgAAAAv BAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAABlFgAAoxgAAK8hAACkGAAA AAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAADAEAAACCgAAQwAL8BgAAACAAAAAFgCKADAEAAC/ AQAAEAD/AQAACAAAAA/wEAAAABAZAACVGgAA8h8AADUcAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAA FgAPAATwTgAAAAICCvAIAAAAMQQAAAILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMDAAAAAAAAD/AQ AAAAZxYAAPIcAACzIQAA8xwAAAAAEfAEAAAAAQAAAA8ABPBOAAAAAgIK8AgAAAAyBAAAQgsAADMA C/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAABpFgAAAB4AALUhAAABHgAAAAAR8AQAAAAB AAAADwAE8GAAAACiDArwCAAAADMEAAACCgAAQwAL8BgAAACAAAAAFwCKADMEAAC/AQAAEAD/AQAA CAAAAA/wEAAAACwYAACyGwAA+iAAADAdAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAFwAPAATwYAAA AKIMCvAIAAAANAQAAAIKAABDAAvwGAAAAIAAAAAYAIoANAQAAL8BAAAQAP8BAAAIAAAAD/AQAAAA 2hgAAMIcAACKHwAAYh4AAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAYAA8ABPBOAAAAAgIK8AgAAAA1 BAAAAgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAAAnCwAADh8AAHMWAAAPHwAA AAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAADYEAAACCgAAQwAL8BgAAACAAAAAGQCKADYEAAC/ AQAAEAD/AQAACAAAAA/wEAAAABQPAADmHQAALRQAAIYfAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAA GQAPAATwYAAAAKIMCvAIAAAANwQAAAIKAABDAAvwGAAAAIAAAAAaAIoANwQAAL8BAAAQAP8BAAAI AAAAD/AQAAAAVBcAAIwjAAAJIgAACiUAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAaAA8ABPBgAAAA ogwK8AgAAAA4BAAAAgoAAEMAC/AYAAAAgAAAABsAigA4BAAAvwEAABAA/wEAAAgAAAAP8BAAAAD4 GAAAnCQAAKgfAAA8JgAAAAAR8AQAAAABAAAAAAAN8AQAAAAAABsADwAE8E4AAAACAgrwCAAAADkE AABCCwAAMwAL8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAFoWAAAHJwAAmiEAAAknAAAA ABHwBAAAAAEAAAAPAATwYAAAAKIMCvAIAAAAOgQAAAIKAABDAAvwGAAAAIAAAAAcAIoAOgQAAL8B AAAQAP8BAAAIAAAAD/AQAAAAvRgAANolAACHIAAAeicAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAc AA8ABPBOAAAAAgIK8AgAAAA7BAAAAgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAA AABYFgAANigAAKYhAAA3KAAAAAAR8AQAAAABAAAADwAE8E4AAAACAgrwCAAAADwEAAACCwAAMwAL 8BIAAADOAQYAAADRAQEAAAADAwAAAAAAAA/wEAAAAGUWAABhKQAAlSEAAGIpAAAAABHwBAAAAAEA AAAPAATwYAAAAKIMCvAIAAAAPQQAAAIKAABDAAvwGAAAAIAAAAAdAIoAPQQAAL8BAAAQAP8BAAAI AAAAD/AQAAAAahkAADcoAAADHwAA1ykAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAdAA8ABPBOAAAA AgIK8AgAAAA+BAAAQgsAADMAC/ASAAAAzgEGAAAA0QEBAAAAAwMAAAAAAAAP8BAAAABVFgAAfCoA AJUhAAB+KgAAAAAR8AQAAAABAAAADwAE8GAAAACiDArwCAAAAD8EAAACCgAAQwAL8BgAAACAAAAA HgCKAD8EAAC/AQAAEAD/AQAACAAAAA/wEAAAAJYXAABBKQAAhiEAAOEqAAAAABHwBAAAAAEAAAAA AA3wBAAAAAAAHgAPAATwTgAAAAICCvAIAAAAQAQAAEILAAAzAAvwEgAAAM4BBgAAANEBAQAAAAMD AAAAAAAAD/AQAAAATRYAAKorAACNIQAArCsAAAAAEfAEAAAAAQAAAA8ABPBgAAAAogwK8AgAAABB BAAAAgoAAEMAC/AYAAAAgAAAAB8AigBBBAAAvwEAABAA/wEAAAgAAAAP8BAAAACmGAAAfioAAIcg AAAeLAAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAB8ADwAE8GAAAACiDArwCAAAAEIEAAACCgAAQwAL 8BgAAACAAAAAIACKAEIEAAC/AQAAEAD/AQAACAAAAA/wEAAAAOkYAAAKJwAAXR8AAKooAAAAABHw BAAAAAEAAAAAAA3wBAAAAAAAIAAPAATwdAAAAKIMCvAIAAAAQwQAAAIKAABDAAvwGAAAAIAAAAAh AIoAQwQAAL8BAAAQAP8BAAAIACMAIvEMAAAAqgMAAAAPPwUAAAEAAAAP8BAAAAAzGgAArCsAAHEf AABMLQAAAAAR8AQAAAABAAAAAAAN8AQAAAAAACEADwAE8GIAAAACAgrwCAAAAEQEAABCCwAAMwAL 8BIAAADOAQYAAADRAQEAAAADAwAAAAAjACLxDAAAAKoDAAQADz8FAAABAAAAD/AQAAAARxYAAAYu AACRIQAABy4AAAAAEfAEAAAAAQAAAA8ABPBiAAAAAgIK8AgAAABFBAAAAgsAADMAC/ASAAAAzgEG AAAA0QEBAAAAAwMAAAAAIwAi8QwAAACqAwAAAA8/BQAAAQAAAA/wEAAAAFYWAADeLAAAhiEAAN8s AAAAABHwBAAAAAEAAAAPAATwdAAAAKIMCvAIAAAARgQAAAIKAABDAAvwGAAAAIAAAAAiAIoARgQA AL8BAAAQAP8BAAAIACMAIvEMAAAAqgMAAAAPPwUAAAEAAAAP8BAAAAD4GAAA3ywAANofAAB/LgAA AAAR8AQAAAABAAAAAAAN8AQAAAAAACIADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/ AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAfAgXwIAQAAAEAEvAYAAAA AQAAAAAAAAAAAAAAPgQAAP//////////AQAS8BgAAAACAAAAAAAAAAAAAAA8BAAA//////////8B ABLwGAAAAAMAAAAAAAAAAAAAACAEAAD//////////wEAEvAYAAAABAAAAAAAAAAAAAAAEQQAAP// ////////AQAS8BgAAAAFAAAAAAAAAAAAAAANBAAA//////////8BABLwGAAAAAYAAAAAAAAAAAAA AAYEAAD//////////wEAEvAYAAAABwAAAAAAAAAAAAAAOQQAAP//////////AQAS8BgAAAAIAAAA AAAAAAAAAAAvBAAA//////////8BABLwGAAAAAkAAAAAAAAAAAAAAAsEAAD//////////wEAEvAY AAAACgAAAAAAAAAAAAAAJwQAAP//////////AQAS8BgAAAALAAAAAAAAAAAAAAAUBAAA//////// //8BABLwGAAAAAwAAAAAAAAAAAAAACsEAAD//////////wEAEvAYAAAADQAAAAAAAAAAAAAABQQA AP//////////AQAS8BgAAAAOAAAAAAAAAAAAAAAaBAAA//////////8BABLwGAAAAA8AAAAAAAAA AAAAABMEAAD//////////wEAEvAYAAAAEAAAAAAAAAAAAAAAHwQAAP//////////AQAS8BgAAAAR AAAAAAAAAAAAAAAlBAAA//////////8BABLwGAAAABIAAAAAAAAAAAAAADUEAAD//////////wEA EvAYAAAAEwAAAAAAAAAAAAAAEgQAAP//////////AQAS8BgAAAAUAAAAAAAAAAAAAAAxBAAA//// //////8BABLwGAAAABUAAAAAAAAAAAAAABAEAAD//////////wEAEvAYAAAAFgAAAAAAAAAAAAAA QAQAAP//////////AQAS8BgAAAAXAAAAAAAAAAAAAAAZBAAA//////////8BABLwGAAAABgAAAAA AAAAAAAAACwEAAD//////////wEAEvAYAAAAGQAAAAAAAAAAAAAAFwQAAP//////////AQAS8BgA AAAaAAAAAAAAAAAAAAA7BAAA//////////8BABLwGAAAABsAAAAAAAAAAAAAABsEAAD///////// /wEAEvAYAAAAHAAAAAAAAAAAAAAABAQAAP//////////AQAS8BgAAAAdAAAAAAAAAAAAAAAhBAAA //////////8BABLwGAAAAB4AAAAAAAAAAAAAACgEAAD//////////wEAEvAYAAAAHwAAAAAAAAAA AAAAMgQAAP//////////AQAS8BgAAAAgAAAAAAAAAAAAAABEBAAA//////////8BABLwGAAAACEA AAAAAAAAAAAAAEUEAAD//////////xkAAABhAgAAAgQAAAAAAAAAAAAAcCEAAKsnAAB0gCIAAAAA AAAAHQAAAFsAAABiAAAAgQAAAI4AAADcAAAA4wAAADcBAAA5AQAAbwEAAHIBAADHAQAAyQEAAOoB AADwAQAA9wEAAAACAAAcAgAAHwIAACECAAAqAgAAYgIAAAcABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAAAAAAB0AAACFAAAAjgAAALcAAAC9AAAALAEAADMBAACNAQAA lAEAALwBAADDAQAAYgIAAAcABwAzAAcAMwAHADMABwAzAAcAMwAHAAIAAAAEAAAACAAAAOUAAAAA AAAAAQAAAC0q0gAHbPsAAAAAAB0AAAAfAAAAAAAAAAEAAAD/QAGAAQAcAAAAHAAAAAB4EAMBAAEA HAAAAAAAAAAcAAAAAAAAAAIQAAAAAAAAAGECAACoAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcA bgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAFAAAARx6Q AQAAAgIGAwUEBQIDBIcqACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAA UgBvAG0AYQBuAAAANR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBt AGIAbwBsAAAAMy6QAQAAAgsGBAICAgICBIcqACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEA bAAAADcukAEAAAIPBQICAgQDAgTvAgCgeyAAQAAAAAAAAAAAnwAAAAAAAABDAGEAbABpAGIAcgBp AAAAQR6QAQAAAgQFAwUEBgMCBO8CAKDrIABCAAAAAAAAAACfAAAAAAAAAEMAYQBtAGIAcgBpAGEA IABNAGEAdABoAAAAIgAEAHEIiBgA8NACAABoAQAAAAAyUMGGNlDBhgAAAAABAAAAAAAEAAAAGQAA AAEAAQAAAAQAA5ABAAAAWgAAAAUCAAABAAEAAAAEAAAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKAFoAW0ALQAgYEyMAAAAAAAAAAAAAAAAAAAHAAAAF4CAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA AAAACDKDUQDwEAAIAPz9AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhIUAAAAAAJ8P8PAQgkUAAA 5AQAAP///3////9/////f////3////9/////f////38HbPsAAAQAADIAAAAAAAAAAAAAAAAAAAAA AAAAAAAhBAAAAAAAAAAAAAAAAAAAAAAAABAcAAAEAAAAAAAAAAAAeAAAAHgAAAAAAAAAAAAAAKAF AAD//xIAAAAAAAAAAAAAAAAAAAATAEoAYQB0AGkAIABLAGEAbABpAG4AZwBnAGEAIABQAHIAYQBq AGEAEwBKAGEAdABpACAASwBhAGwAaQBuAGcAZwBhACAAUAByAGEAagBhAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACAAQAA EQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACwAAAABQAAAMwAAAAGAAAA2AAAAAcAAADk AAAACAAAAPQAAAAJAAAAEAEAABIAAAAcAQAACgAAADwBAAAMAAAASAEAAA0AAABUAQAADgAAAGAB AAAPAAAAaAEAABAAAABwAQAAEwAAAHgBAAACAAAA5AQAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAA AB4AAAAUAAAASmF0aSBLYWxpbmdnYSBQcmFqYQAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAA CAAAAE5vcm1hbAAAHgAAABQAAABKYXRpIEthbGluZ2dhIFByYWphAB4AAAAEAAAAMQAAAB4AAAAY AAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAAAAAAAAAAAAQAAAAABU8w3oUsgBQAAAAABs AJ3oUsgBAwAAAAEAAAADAAAABAAAAAMAAAAZAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8A AAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA9AAAAAwAAAABAAAA aAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEAAACYAAAAFwAAAKAAAAALAAAAqAAAABAAAACw AAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAAANUAAAACAAAA5AQAAB4AAAAQAAAAS2FsaW5n Z2EgQ29ycAAAAAMAAAABAAAAAwAAAAEAAAADAAAAHAAAAAMAAAAAAAwACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAA AAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAA/v///w0AAAAOAAAADwAAABAAAAARAAAA EgAAABMAAAD+////FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAg AAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4A AAAvAAAAMAAAADEAAAAyAAAA/v///zQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAD+////PAAA AD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAP7////9////RQAAAP7////+/////v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////UgBvAG8AdAAgAEUA bgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH/ /////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA0FE1o+hSyAFHAAAAgAAAAAAA AABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAwAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAFAAAAB09AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhYAAAAAAAAFAFMAdQBtAG0AYQBy AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMAAAAAEAAAAAAA AAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA AAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAOwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQD+/wMKAAD/////BgkC AAAAAADAAAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgOTctMjAwMyBEb2N1bWVudAAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_Part_11016_23566565.1199906146345 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_Part_11016_23566565.1199906146345-- From sip-bounces@ietf.org Wed Jan 09 14:28:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgZj-0007qS-Hg; Wed, 09 Jan 2008 14:26:55 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCgZi-0007qM-4A for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 14:26:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCgZh-0007qE-PI for sip@ietf.org; Wed, 09 Jan 2008 14:26:53 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCgZh-000760-3R for sip@ietf.org; Wed, 09 Jan 2008 14:26:53 -0500 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m09JQkCZ008299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Jan 2008 13:26:47 -0600 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05494DD@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D05494DD@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BC9F2EF-86C7-4D79-BDB1-F76A9E900D51@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases? Date: Wed, 9 Jan 2008 13:26:22 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 9, 2008, at 3:58 AM, Elwell, John wrote: > Hadriel, > > Some possible further use cases: > > 1. Along the same lines as 6.2/6.3/6.4 (vcard, user-icon, > vcalendar), we > could also consider pictures, movie clips, audio clips, etc.. Of > course, > we don't want to encourage sending anything too big along the > signalling > path, so we would need to consider where to draw the line. So, how is this different from MESSAGE with the "gruu" as the target? Does it gain anything from being in-dialog? Does it gain from the specific content-type and usage negotiation? If so, does this mean we should fix this problem for MESSAGE too? > > 2. We already have the conference event package for obtaining > conference > membership details. In many situations the conference focus is also > the > source of such notifications, so the subscribe-initiated dialog > parallels the INVITE-initiate dialog, which is rather wasteful. It > would > be great to subscribe as part of the INVITE transaction and receive > notifications along the INVITE-initiated dialog. I like this one a lot. It could rip a LOT of the overhead out of conference setup, especially for conferences with restricted functionality. A variant of this is synchronized browsing within the conference -- INFO messages that convey the current URL that should be rendered. > > 3. Concerning mobility, I like the suggestion in 6.8 (geo-location > information). Also, there may sometimes be intermediaries on the > signalling path (B2BUAs) that are involved in mobility in some way, > and > these might be interested in movement-related notifications (e.g., a > dual mode device moving in or out of WLAN range). > > 4. The use of offer-answer to achieve hold-retrieve fails to give an > explicit indication of what is happening. An explicit indication of > things like hold, retrieve, microphone mute, speaker mute, camera > on/off, recorder on/off, etc. might be quite helpful. Of course, there > will normally be an offer-answer exchange at the same time, so > inclusion > of the notification in a re-INVITE or UPDATE request might be more > useful than using INFO. I suspect adding something to the reINVITE to convey explicit semantics would be much better than an INFO here. > > 5. Concerning 6.7 (soft-key labels), a problem here is that the > notifying UA might not have knowledge of soft key availability at the > receiving UA. In certain closed environments (e.g., involving a UA and > its local voicemail server) it may work, but I am not sure it would > work > well in general. Having said that, where it does work, perhaps other > parameters at the device can be controlled in this way, e.g., > microphone > and speaker volume (especially if this control is based on say a web > interface, so the user is really controlling his/her own settings from > the web page rather than directly on the device). A soft-key INFO package would need to describe availability. This is a fundamental problem from KPML, and to the extent it is solvable by KPML in a SUBSCRIBE dialog, it should be solvable in an INVITE dialog. > > 6. When a B2BUA performs 3PCC there is plenty of scope for the UAs to > lose track of what is happening. For example, when a B2BUA holds, > retrieves, transfers calls, joins calls, pre-empts calls, etc., > there is > currently no explicit information - only perhaps a re-INVITE request. > Thus it can be difficult to know how to interpret things like > identity. > Say a UA receives a re-INVITE request with a new PAI, it might deduce > that something like call transfer has occurred. However, if it > receives > a re-INVITE request without a PAI, does it mean the previous PAI is > still valid, or does it mean, following transfer, there is no > longer any > identity available? Of course, INFO might not always be the most > appropriate method to use for such notification if an offer-answer > exchange is needed at the same time. I'm thinking this is totally NOT an INFO problem. If it needs to be solved, it needs to happen in the 3PCC reINVITE sequence. > > 7. There might be some usages to do with interworking with TDM, e.g., > advice of charge during a call, user-to-user information during a > call. > Clearly, all the old TDM interworking mid-call events work better with the new INFO. Advice-of-charge would appear to be easily solved with INFO, except that some use cases for it require delivering the final AOC after the call has completed. There may some flexibility on this, of course, but a dialog-correlated MESSAGE to the GRUU may be cleaner. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 14:35:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCggt-0006jQ-4P; Wed, 09 Jan 2008 14:34:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCggr-0006Ys-A3 for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 14:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCggq-0006Ws-Vn for sip@ietf.org; Wed, 09 Jan 2008 14:34:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCggq-0000N2-Cr for sip@ietf.org; Wed, 09 Jan 2008 14:34:16 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6D5D21184; Wed, 9 Jan 2008 20:34:15 +0100 (CET) X-AuditID: c1b4fb3e-b0ea3bb00000459d-8c-478521b720a2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83E602009A; Wed, 9 Jan 2008 20:34:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 20:34:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2008 20:34:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Accept ABNF Thread-Index: AchSzBq1jJI0SVz/Ts2YtJ3bh1GVwAAIiICwAAGQ2r4= References: <4784D875.7080508@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 09 Jan 2008 19:34:15.0381 (UTC) FILETIME=[9E72B850:01C852F6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Sip] Question on Accept ABNF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 I appologize if the following issue has already been dealt with. =20 In RFC3261 the ABNF for the Accept header is the following: =20 Accept =3D "Accept" HCOLON[ accept-range *(COMMA = accept-range) ] accept-range =3D media-range *(SEMI accept-param) media-range =3D ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH = m-subtype )) *( SEMI m-parameter ) accept-param =3D ("q" EQUAL qvalue) / generic-param qvalue =3D ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." = 0*3("0") ] ) generic-param =3D token [ EQUAL gen-value ] gen-value =3D token / host / quoted-string ... m-parameter =3D m-attribute EQUAL m-value m-attribute =3D token m-value =3D token / quoted-string Now, when I receive: Accept: xxxx/yyyy;myParam=3DisThis ...how does my parser know whether "myParam" is a m-parameter, or an = accept-param? =20 In RFC2616 (HTTP) it is solved by specifying that the first accept-param = MUST be a "q" value, so unless you also have a "q" m-parameter you know = that anything that comes before "q" is m-parameter, and the rest = (including "q" is accept-param): =20 accept-params =3D ";" "q" "=3D" qvalue *( accept-extension ) RFC2616 also says: =20 "Each media-range MAY be followed by one or more accept-params, = beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range = parameter(s) from the accept-params." =20 ...and: =20 "Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q"." =20 =20 Now, RFC3261 DOES say that Accept follows the syntax defined in RFC2616, = but then it is confusing that the 3261 Accept ABNF is not identical. =20 =20 Regards, =20 Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 15:44:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JChlT-0006Nl-U8; Wed, 09 Jan 2008 15:43:07 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JChlS-0006Ng-JD for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 15:43:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JChlS-0006NY-8q for sip@ietf.org; Wed, 09 Jan 2008 15:43:06 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JChlR-00006b-V6 for sip@ietf.org; Wed, 09 Jan 2008 15:43:06 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jan 2008 15:43:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2008 15:43:06 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosenberg-sip-ua-loose-route-01: lr impacts Thread-Index: AchTADyeVWYCeHRlQ1uB6+CM5/LNow== From: "Brett Tate" To: , X-OriginalArrivalTime: 09 Jan 2008 20:43:10.0828 (UTC) FILETIME=[3F5DDAC0:01C85300] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Sip] draft-rosenberg-sip-ua-loose-route-01: lr impacts X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, Draft-rosenberg-sip-ua-loose-route-01 proposes the use of 'lr' parameter within registered and redirected contact URIs. The 'lr' is currently not listed as optional within RFC3261. Thus the additional impact upon registrars not supporting this draft should maybe be reflected with the Backwards Compatibility section. Concerning the use of 'lr' within registered contact, what contact (contact-param) should be placed within the Route? More specifically, should it be the one received within REGISTER or the one sent within the REGISTER response? I ask because there are Contact header parameters (contact-params) which can be added or modified by the registrar. Concerning the use of 'lr' within registered contact, the draft should mention what should occur for contact-params applicable to registration but not relevant (or would appear strange) within Route. The 'q' and 'expires' parameters are some which fall into this category. Section 10 currently shows none of the contact-params being copied to the rr-param portion of the route-param. Was this intentional or an error within the example? There are also sip-uri parameters which are valid within a Contact but not currently optional to include within Route. And some of these like 'ttl' might also be valid within a request-uri. I thought that I'd mention it incase you think it warrants discussion within the draft. Thanks, Brett _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 15:51:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCht4-0000aS-BC; Wed, 09 Jan 2008 15:50:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCht3-0000aN-LH for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 15:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCht3-0000aC-BR for sip@ietf.org; Wed, 09 Jan 2008 15:50:57 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JChsz-0001W4-CC for sip@ietf.org; Wed, 09 Jan 2008 15:50:57 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUE00J2E9WM69@siemenscomms.co.uk> for sip@ietf.org; Wed, 09 Jan 2008 20:50:46 +0000 (GMT) Date: Wed, 09 Jan 2008 20:50:45 +0000 From: "Elwell, John" Subject: RE: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases? In-reply-to: <1BC9F2EF-86C7-4D79-BDB1-F76A9E900D51@softarmor.com> To: Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0549694@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases? thread-index: AchS9nvcKYINLSBLR0Oqmw8kPkMPzwACd9kA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D05494DD@GBNTHT12009MSX.gb002.siemens.net> <1BC9F2EF-86C7-4D79-BDB1-F76A9E900D51@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Thanks for your comments. More below. John=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 09 January 2008 19:26 > To: Elwell, John > Cc: Hadriel Kaplan; IETF SIP List > Subject: Re: [Sip] draft-kaplan-sip-info-use-cases-00 - more=20 > use cases? >=20 >=20 > On Jan 9, 2008, at 3:58 AM, Elwell, John wrote: >=20 > > Hadriel, > > > > Some possible further use cases: > > > > 1. Along the same lines as 6.2/6.3/6.4 (vcard, user-icon, =20 > > vcalendar), we > > could also consider pictures, movie clips, audio clips, etc.. Of =20 > > course, > > we don't want to encourage sending anything too big along the =20 > > signalling > > path, so we would need to consider where to draw the line. >=20 > So, how is this different from MESSAGE with the "gruu" as the=20 > target? =20 > Does it gain anything from being in-dialog? Does it gain from the =20 > specific content-type and usage negotiation? If so, does this=20 > mean we =20 > should fix this problem for MESSAGE too? [JRE] Not very different, except that it is correlated to the dialog without having to do extra work such as using Target-Dialog. Whether dependence on GRUU is seen as a significant problem I am not sure. >=20 > > > > 2. We already have the conference event package for obtaining =20 > > conference > > membership details. In many situations the conference focus=20 > is also =20 > > the > > source of such notifications, so the subscribe-initiated dialog > > parallels the INVITE-initiate dialog, which is rather wasteful. It =20 > > would > > be great to subscribe as part of the INVITE transaction and receive > > notifications along the INVITE-initiated dialog. >=20 > I like this one a lot. It could rip a LOT of the overhead out of =20 > conference setup, especially for conferences with restricted =20 > functionality. >=20 > A variant of this is synchronized browsing within the conference -- =20 > INFO messages that convey the current URL that should be rendered. [JRE] Another good one. >=20 > > > > 3. Concerning mobility, I like the suggestion in 6.8 (geo-location > > information). Also, there may sometimes be intermediaries on the > > signalling path (B2BUAs) that are involved in mobility in=20 > some way, =20 > > and > > these might be interested in movement-related notifications (e.g., a > > dual mode device moving in or out of WLAN range). > > > > 4. The use of offer-answer to achieve hold-retrieve fails to give an > > explicit indication of what is happening. An explicit indication of > > things like hold, retrieve, microphone mute, speaker mute, camera > > on/off, recorder on/off, etc. might be quite helpful. Of=20 > course, there > > will normally be an offer-answer exchange at the same time, so =20 > > inclusion > > of the notification in a re-INVITE or UPDATE request might be more > > useful than using INFO. >=20 > I suspect adding something to the reINVITE to convey explicit =20 > semantics would be much better than an INFO here. [JRE] Yes. I guess what I am driving at is that if we had a INVITE-initiated dialog notification mechanism, it should not be restricted to INFO, but should be applicable to other mid-dialog methods where appropriate, e.g., re-INVITE, UPDATE, BYE. >=20 > > > > 5. Concerning 6.7 (soft-key labels), a problem here is that the > > notifying UA might not have knowledge of soft key=20 > availability at the > > receiving UA. In certain closed environments (e.g.,=20 > involving a UA and > > its local voicemail server) it may work, but I am not sure=20 > it would =20 > > work > > well in general. Having said that, where it does work, perhaps other > > parameters at the device can be controlled in this way, e.g., =20 > > microphone > > and speaker volume (especially if this control is based on say a web > > interface, so the user is really controlling his/her own=20 > settings from > > the web page rather than directly on the device). >=20 > A soft-key INFO package would need to describe availability. This is =20 > a fundamental problem from KPML, and to the extent it is solvable by =20 > KPML in a SUBSCRIBE dialog, it should be solvable in an INVITE dialog. >=20 > > > > 6. When a B2BUA performs 3PCC there is plenty of scope for=20 > the UAs to > > lose track of what is happening. For example, when a B2BUA holds, > > retrieves, transfers calls, joins calls, pre-empts calls, etc., =20 > > there is > > currently no explicit information - only perhaps a=20 > re-INVITE request. > > Thus it can be difficult to know how to interpret things like =20 > > identity. > > Say a UA receives a re-INVITE request with a new PAI, it=20 > might deduce > > that something like call transfer has occurred. However, if it =20 > > receives > > a re-INVITE request without a PAI, does it mean the previous PAI is > > still valid, or does it mean, following transfer, there is no =20 > > longer any > > identity available? Of course, INFO might not always be the most > > appropriate method to use for such notification if an offer-answer > > exchange is needed at the same time. >=20 > I'm thinking this is totally NOT an INFO problem. If it needs to be =20 > solved, it needs to happen in the 3PCC reINVITE sequence. [JRE] In general, yes. I am not sure whether there are any exceptions where INFO might still fit. >=20 > > > > 7. There might be some usages to do with interworking with=20 > TDM, e.g., > > advice of charge during a call, user-to-user information during a =20 > > call. > > >=20 > Clearly, all the old TDM interworking mid-call events work better =20 > with the new INFO. Advice-of-charge would appear to be easily solved =20 > with INFO, except that some use cases for it require delivering the =20 > final AOC after the call has completed. There may some=20 > flexibility on =20 > this, of course, but a dialog-correlated MESSAGE to the GRUU may be =20 > cleaner. >=20 > -- > Dean >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 09 23:16:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCooy-00005w-C2; Wed, 09 Jan 2008 23:15:12 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCoox-00005r-9w for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 23:15:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCoow-0008U4-Uz for sip@ietf.org; Wed, 09 Jan 2008 23:15:11 -0500 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCoou-0000LC-Bw for sip@ietf.org; Wed, 09 Jan 2008 23:15:08 -0500 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JUE00FIEUEY7U@mailout1.samsung.com> for sip@ietf.org; Thu, 10 Jan 2008 13:13:46 +0900 (KST) Received: from mahesha ([107.108.74.189]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JUE00M76UEWG2@mmp2.samsung.com> for sip@ietf.org; Thu, 10 Jan 2008 13:13:46 +0900 (KST) Date: Thu, 10 Jan 2008 09:46:17 +0530 From: Mahesh Anjanappa Subject: Re: [Sip] Question on RFC3840/3841 To: Paul Kyzivat Message-id: <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org hi Paul, Sorry there is a mistake in Contact header i described.Following is what i wanted to: Contact:sip:alice@atlanta.com; Contact:audio;duplex=full; Contact:video;duplex=recieve-only; Thanks Mahesh ----- Original Message ----- From: "Mahesh Anjanappa" To: "Paul Kyzivat" Cc: ; "Christer Holmberg" Sent: Wednesday, January 09, 2008 10:48 PM Subject: Re: [Sip] Question on RFC3840/3841 > Thanks Paul. > So would it be right if i have a Contact Headers describing Duplex Audio & > one-way Video Capabilities as follows? > > Contact:sip:alice@atlanta.com; > Contact:sip:audio;duplex=full; > Contact:sip:video;duplex=recieve-only; > > NOTE: The Predicate(for above) for which i'm attempting is > & ( & (sip.audio) (sip.duplex=full) ) > ( & (sip.video) (sip.duplex=receive-only) ) > > regards > Mahesh > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Mahesh Anjanappa" > Cc: "Christer Holmberg" ; > Sent: Wednesday, January 09, 2008 7:55 PM > Subject: Re: [Sip] Question on RFC3840/3841 > > >> >> >> Mahesh Anjanappa wrote: >>> hi >>> That is my understanding as well. But if that is the case then it should >>> apply to Contact header as well >>> when describing Capabilities using Feature parameters in Contact Header. >>> But i'm not sure if it applies the same way. I had posted this question >>> long ago but didnt get any comments on it. >> >> The rule forbidding multiple instances of a parameter applies to all >> headers, so it applies to Contact. E.g. the following is illegal: >> >> Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" >> >> Paul > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 10 01:01:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCqT5-0008SQ-VZ; Thu, 10 Jan 2008 01:00:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCqT4-0008SJ-HV for sip-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 01:00:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCqT4-0008S9-6U for sip@ietf.org; Thu, 10 Jan 2008 01:00:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCqT3-00025k-HT for sip@ietf.org; Thu, 10 Jan 2008 01:00:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C6CA6211BA; Thu, 10 Jan 2008 07:00:26 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-25-4785b47a3a19 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 98E7D2169A; Thu, 10 Jan 2008 07:00:26 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 07:00:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on RFC3840/3841 Date: Thu, 10 Jan 2008 07:00:25 +0100 Message-ID: In-Reply-To: <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on RFC3840/3841 Thread-Index: AchTPzYXn2dd8gh6QQaIfqe7ot0ndgADooYw References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> From: "Christer Holmberg" To: "Mahesh Anjanappa" , "Paul Kyzivat" X-OriginalArrivalTime: 10 Jan 2008 06:00:26.0251 (UTC) FILETIME=[186E85B0:01C8534E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Shouldn't each Contact also contain "alice@atlanta.com"? Also, why do you have ";" at the end of each Contact? Regards, Christer=20 > -----Original Message----- > From: Mahesh Anjanappa [mailto:mahesha@samsung.com]=20 > Sent: 10. tammikuuta 2008 6:16 > To: Paul Kyzivat > Cc: sip@ietf.org; Christer Holmberg > Subject: Re: [Sip] Question on RFC3840/3841 >=20 > hi Paul, > Sorry there is a mistake in Contact header i=20 > described.Following is what i wanted to: > Contact:sip:alice@atlanta.com; > Contact:audio;duplex=3Dfull; > Contact:video;duplex=3Drecieve-only; >=20 > Thanks > Mahesh > ----- Original Message ----- > From: "Mahesh Anjanappa" > To: "Paul Kyzivat" > Cc: ; "Christer Holmberg"=20 > > Sent: Wednesday, January 09, 2008 10:48 PM > Subject: Re: [Sip] Question on RFC3840/3841 >=20 >=20 > > Thanks Paul. > > So would it be right if i have a Contact Headers describing=20 > Duplex Audio &=20 > > one-way Video Capabilities as follows? > > > > Contact:sip:alice@atlanta.com; > > Contact:sip:audio;duplex=3Dfull; > > Contact:sip:video;duplex=3Drecieve-only; > > > > NOTE: The Predicate(for above) for which i'm attempting is > > & ( & (sip.audio) (sip.duplex=3Dfull) ) > > ( & (sip.video) (sip.duplex=3Dreceive-only) ) > > > > regards > > Mahesh > > > > ----- Original Message -----=20 > > From: "Paul Kyzivat" > > To: "Mahesh Anjanappa" > > Cc: "Christer Holmberg" ;=20 > > > Sent: Wednesday, January 09, 2008 7:55 PM > > Subject: Re: [Sip] Question on RFC3840/3841 > > > > > >> > >> > >> Mahesh Anjanappa wrote: > >>> hi > >>> That is my understanding as well. But if that is the case=20 > then it should=20 > >>> apply to Contact header as well > >>> when describing Capabilities using Feature parameters in=20 > Contact Header. > >>> But i'm not sure if it applies the same way. I had posted=20 > this question=20 > >>> long ago but didnt get any comments on it. > >> > >> The rule forbidding multiple instances of a parameter=20 > applies to all=20 > >> headers, so it applies to Contact. E.g. the following is illegal: > >> > >> Contact:sip:alice@atlanta.com;methods=3D"INVITE";methods=3D"CANCEL" > >> > >> Paul > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 10 07:41:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCwik-00077l-Uo; Thu, 10 Jan 2008 07:41:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCwij-00077g-Ip for sip-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 07:41:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCwij-00077Y-99 for sip@ietf.org; Thu, 10 Jan 2008 07:41:17 -0500 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCwig-0005x9-Sj for sip@ietf.org; Thu, 10 Jan 2008 07:41:17 -0500 Received: from epmmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JUF00A6KHVTBY@mailout1.samsung.com> for sip@ietf.org; Thu, 10 Jan 2008 21:40:41 +0900 (KST) Received: from mahesha ([107.108.74.189]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JUF00KYWHVSOV@mmp1.samsung.com> for sip@ietf.org; Thu, 10 Jan 2008 21:40:41 +0900 (KST) Date: Thu, 10 Jan 2008 18:13:06 +0530 From: Mahesh Anjanappa Subject: Re: [Sip] Question on RFC3840/3841 To: Christer Holmberg , Paul Kyzivat Message-id: <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes the ';' is a mistake. But i'm not sure if each Contact should contain "alice@atlanta.com" because the predicate that i'm trying to represent is as follows meanig to say alice supports a communication which whose capability is Duplex Audio + One Way Video. If each of the COntact contains alice@atlanta.com wouldnt it be interpreted as " alice supports duplex audio and oneway video separatley and not both at the same time". Actually i'm not quite sure how to represesnt the predicate in the Contact header correctly, hence my Queries. It all stems from the statement which you too noted " There MUST only be one instance of any feature tag in feature-param." in RFC 3840 Predicate: ------------ & ( & (sip.audio) (sip.duplex=full) ) ( & (sip.video) (sip.duplex=receive-only) ) regards Mahesh ----- Original Message ----- From: "Christer Holmberg" To: "Mahesh Anjanappa" ; "Paul Kyzivat" Cc: Sent: Thursday, January 10, 2008 11:30 AM Subject: RE: [Sip] Question on RFC3840/3841 Shouldn't each Contact also contain "alice@atlanta.com"? Also, why do you have ";" at the end of each Contact? Regards, Christer > -----Original Message----- > From: Mahesh Anjanappa [mailto:mahesha@samsung.com] > Sent: 10. tammikuuta 2008 6:16 > To: Paul Kyzivat > Cc: sip@ietf.org; Christer Holmberg > Subject: Re: [Sip] Question on RFC3840/3841 > > hi Paul, > Sorry there is a mistake in Contact header i > described.Following is what i wanted to: > Contact:sip:alice@atlanta.com; > Contact:audio;duplex=full; > Contact:video;duplex=recieve-only; > > Thanks > Mahesh > ----- Original Message ----- > From: "Mahesh Anjanappa" > To: "Paul Kyzivat" > Cc: ; "Christer Holmberg" > > Sent: Wednesday, January 09, 2008 10:48 PM > Subject: Re: [Sip] Question on RFC3840/3841 > > > > Thanks Paul. > > So would it be right if i have a Contact Headers describing > Duplex Audio & > > one-way Video Capabilities as follows? > > > > Contact:sip:alice@atlanta.com; > > Contact:sip:audio;duplex=full; > > Contact:sip:video;duplex=recieve-only; > > > > NOTE: The Predicate(for above) for which i'm attempting is > > & ( & (sip.audio) (sip.duplex=full) ) > > ( & (sip.video) (sip.duplex=receive-only) ) > > > > regards > > Mahesh > > > > ----- Original Message ----- > > From: "Paul Kyzivat" > > To: "Mahesh Anjanappa" > > Cc: "Christer Holmberg" ; > > > Sent: Wednesday, January 09, 2008 7:55 PM > > Subject: Re: [Sip] Question on RFC3840/3841 > > > > > >> > >> > >> Mahesh Anjanappa wrote: > >>> hi > >>> That is my understanding as well. But if that is the case > then it should > >>> apply to Contact header as well > >>> when describing Capabilities using Feature parameters in > Contact Header. > >>> But i'm not sure if it applies the same way. I had posted > this question > >>> long ago but didnt get any comments on it. > >> > >> The rule forbidding multiple instances of a parameter > applies to all > >> headers, so it applies to Contact. E.g. the following is illegal: > >> > >> Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" > >> > >> Paul > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 10 09:21:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCyHE-0000u0-Ia; Thu, 10 Jan 2008 09:21:00 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCyHD-0000tv-NQ for sip-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 09:20:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCyHD-0000tn-Dj for sip@ietf.org; Thu, 10 Jan 2008 09:20:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCyHC-00080t-I0 for sip@ietf.org; Thu, 10 Jan 2008 09:20:59 -0500 X-IronPort-AV: E=Sophos;i="4.24,267,1196668800"; d="scan'208";a="19335880" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2008 06:20:57 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0AEKvlu020142; Thu, 10 Jan 2008 06:20:57 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0AEKjSl028081; Thu, 10 Jan 2008 14:20:52 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 09:20:48 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 09:20:47 -0500 Message-ID: <478629C1.5090404@cisco.com> Date: Thu, 10 Jan 2008 09:20:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mahesh Anjanappa Subject: Re: [Sip] Question on RFC3840/3841 References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> In-Reply-To: <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2008 14:20:47.0975 (UTC) FILETIME=[FEC60F70:01C85393] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5612; t=1199974857; x=1200838857; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20RFC3840/3841 |Sender:=20; bh=oe0HuLv374cj4Wbjk3uFrN1TApXWHHUpfM6E1AG9RTs=; b=PHWk6/Tiz8/HdaAyEjBWbTOloHz0kgHRX28voHpL1cBQwmbubJTcXsf6O/ Tit8RXBbjPsR/ZbcmU+R3qjPHPQ1UCB703AQcqMctrPlAlwvRg/OgXYd5TE9 y3bJ1EuXtl; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org, Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mahesh Anjanappa wrote: > Yes the ';' is a mistake. But i'm not sure if each Contact should > contain "alice@atlanta.com" Well, it has to have a URI to be syntactically correct. Your problem is that you are trying to express something that cannot be expressed with the callee caps syntax. It only maps to a subset of the syntax supported by RFC 2533. > because the predicate that i'm trying to represent is as follows meanig > to say > alice supports a communication which whose capability is Duplex Audio + > One Way Video. You just can't say that. Sorry. A little history may help you to understand, though it won't solve your problem: The initial draft for callerprefs came out a very long time ago. (The earliest draft I have is -03 which came out in november of 2000.) It set the basic syntax and the initial set of capabilities. It was however very weak on the semantics of matching. I eventually got involved because I was interested in it and identified many of the semantic issues. Jonathan and I worked on it for a long time. Eventually, because of some review comments I think, Jonathan tried to define the semantics using RFC 2533 because it was a standard that seemed to be at least partially suitable to the task. (In retrospect this may not have been such a good idea, since it adds an additional layer of complexity.) RFC 2533 syntax is much richer. But it was not a goal to provide that richness. (Mapping that all onto SIP header syntax would be awful.) It was only used as an intermediate form to define the semantics of the SIP headers. Its understood that there are lots of things one might want to express that you can't express. If you aren't already aware of it, you might want to look at RFC 4596 (Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension). Paul > If each of the COntact contains alice@atlanta.com wouldnt it be > interpreted as " alice > supports duplex audio and oneway video separatley and not both at the > same time". > Actually i'm not quite sure how to represesnt the predicate in the > Contact header correctly, hence > my Queries. It all stems from the statement which you too noted " There > MUST only be one instance of any > feature tag in feature-param." in RFC 3840 > > > Predicate: > ------------ > & ( & (sip.audio) (sip.duplex=full) ) > ( & (sip.video) (sip.duplex=receive-only) ) > > regards > Mahesh > ----- Original Message ----- From: "Christer Holmberg" > > To: "Mahesh Anjanappa" ; "Paul Kyzivat" > > Cc: > Sent: Thursday, January 10, 2008 11:30 AM > Subject: RE: [Sip] Question on RFC3840/3841 > > > > Shouldn't each Contact also contain "alice@atlanta.com"? > > Also, why do you have ";" at the end of each Contact? > > Regards, > > Christer > > > >> -----Original Message----- >> From: Mahesh Anjanappa [mailto:mahesha@samsung.com] >> Sent: 10. tammikuuta 2008 6:16 >> To: Paul Kyzivat >> Cc: sip@ietf.org; Christer Holmberg >> Subject: Re: [Sip] Question on RFC3840/3841 >> >> hi Paul, >> Sorry there is a mistake in Contact header i >> described.Following is what i wanted to: >> Contact:sip:alice@atlanta.com; >> Contact:audio;duplex=full; >> Contact:video;duplex=recieve-only; >> >> Thanks >> Mahesh >> ----- Original Message ----- >> From: "Mahesh Anjanappa" >> To: "Paul Kyzivat" >> Cc: ; "Christer Holmberg" >> >> Sent: Wednesday, January 09, 2008 10:48 PM >> Subject: Re: [Sip] Question on RFC3840/3841 >> >> >> > Thanks Paul. >> > So would it be right if i have a Contact Headers describing >> Duplex Audio & >> > one-way Video Capabilities as follows? >> > >> > Contact:sip:alice@atlanta.com; >> > Contact:sip:audio;duplex=full; >> > Contact:sip:video;duplex=recieve-only; >> > >> > NOTE: The Predicate(for above) for which i'm attempting is >> > & ( & (sip.audio) (sip.duplex=full) ) >> > ( & (sip.video) (sip.duplex=receive-only) ) >> > >> > regards >> > Mahesh >> > >> > ----- Original Message ----- > From: "Paul Kyzivat" >> >> > To: "Mahesh Anjanappa" >> > Cc: "Christer Holmberg" ; >> >> > Sent: Wednesday, January 09, 2008 7:55 PM >> > Subject: Re: [Sip] Question on RFC3840/3841 >> > >> > >> >> >> >> >> >> Mahesh Anjanappa wrote: >> >>> hi >> >>> That is my understanding as well. But if that is the case >> then it should >> >>> apply to Contact header as well >> >>> when describing Capabilities using Feature parameters in >> Contact Header. >> >>> But i'm not sure if it applies the same way. I had posted >> this question >> >>> long ago but didnt get any comments on it. >> >> >> >> The rule forbidding multiple instances of a parameter >> applies to all >> >> headers, so it applies to Contact. E.g. the following is illegal: >> >> >> >> Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" >> >> >> >> Paul >> > >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 10 09:42:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCyc4-0000gZ-4N; Thu, 10 Jan 2008 09:42:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCyc2-0000e4-81 for sip-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 09:42:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCyc1-0000bp-T7 for sip@ietf.org; Thu, 10 Jan 2008 09:42:29 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCybz-0008MS-D2 for sip@ietf.org; Thu, 10 Jan 2008 09:42:29 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 586CB213CC; Thu, 10 Jan 2008 15:42:16 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-76-47862ec86a35 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2868A21271; Thu, 10 Jan 2008 15:42:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 15:42:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on RFC3840/3841 Date: Thu, 10 Jan 2008 15:42:14 +0100 Message-ID: In-Reply-To: <478629C1.5090404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on RFC3840/3841 Thread-Index: AchTlKkfbjahEowLQJW4QfKN3RiF1gAAhS/Q References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> <478629C1.5090404@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Mahesh Anjanappa" X-OriginalArrivalTime: 10 Jan 2008 14:42:15.0416 (UTC) FILETIME=[FE25F780:01C85396] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, Regarding the matching, are you saying that reading RFC3840 is enough to understand how the matching is done in a "SIP environment"? Or, do I also need to read RFC2533? I have some questions on the matching, but I will come back to them later. I still have some reading to do. Regards, Christer =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 10. tammikuuta 2008 16:21 > To: Mahesh Anjanappa > Cc: Christer Holmberg; sip@ietf.org > Subject: Re: [Sip] Question on RFC3840/3841 >=20 >=20 >=20 > Mahesh Anjanappa wrote: > > Yes the ';' is a mistake. But i'm not sure if each Contact should=20 > > contain "alice@atlanta.com" >=20 > Well, it has to have a URI to be syntactically correct. >=20 > Your problem is that you are trying to express something that=20 > cannot be expressed with the callee caps syntax. It only maps=20 > to a subset of the syntax supported by RFC 2533. >=20 > > because the predicate that i'm trying to represent is as follows=20 > > meanig to say alice supports a communication which whose=20 > capability is=20 > > Duplex Audio + One Way Video. >=20 > You just can't say that. Sorry. >=20 > A little history may help you to understand, though it won't=20 > solve your > problem: >=20 > The initial draft for callerprefs came out a very long time=20 > ago. (The earliest draft I have is -03 which came out in=20 > november of 2000.) It set the basic syntax and the initial=20 > set of capabilities. >=20 > It was however very weak on the semantics of matching. I=20 > eventually got involved because I was interested in it and=20 > identified many of the semantic issues. Jonathan and I worked=20 > on it for a long time.=20 > Eventually, because of some review comments I think, Jonathan=20 > tried to define the semantics using RFC 2533 because it was a=20 > standard that seemed to be at least partially suitable to the=20 > task. (In retrospect this may not have been such a good idea,=20 > since it adds an additional layer of complexity.) >=20 > RFC 2533 syntax is much richer. But it was not a goal to=20 > provide that richness. (Mapping that all onto SIP header=20 > syntax would be awful.) It was only used as an intermediate=20 > form to define the semantics of the SIP headers. >=20 > Its understood that there are lots of things one might want=20 > to express that you can't express. >=20 > If you aren't already aware of it, you might want to look at=20 > RFC 4596 (Guidelines for Usage of the Session Initiation=20 > Protocol (SIP) Caller Preferences Extension). >=20 > Paul >=20 > > If each of the COntact contains alice@atlanta.com wouldnt it be=20 > > interpreted as " alice supports duplex audio and oneway video=20 > > separatley and not both at the same time". > > Actually i'm not quite sure how to represesnt the predicate in the=20 > > Contact header correctly, hence my Queries. It all stems from the=20 > > statement which you too noted " There MUST only be one=20 > instance of any=20 > > feature tag in feature-param." in RFC 3840 > >=20 > >=20 > > Predicate: > > ------------ > > & ( & (sip.audio) (sip.duplex=3Dfull) ) > > ( & (sip.video) (sip.duplex=3Dreceive-only) ) > >=20 > > regards > > Mahesh > > ----- Original Message ----- From: "Christer Holmberg"=20 > > > > To: "Mahesh Anjanappa" ; "Paul Kyzivat"=20 > > > > Cc: > > Sent: Thursday, January 10, 2008 11:30 AM > > Subject: RE: [Sip] Question on RFC3840/3841 > >=20 > >=20 > >=20 > > Shouldn't each Contact also contain "alice@atlanta.com"? > >=20 > > Also, why do you have ";" at the end of each Contact? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Mahesh Anjanappa [mailto:mahesha@samsung.com] > >> Sent: 10. tammikuuta 2008 6:16 > >> To: Paul Kyzivat > >> Cc: sip@ietf.org; Christer Holmberg > >> Subject: Re: [Sip] Question on RFC3840/3841 > >> > >> hi Paul, > >> Sorry there is a mistake in Contact header i > >> described.Following is what i wanted to: > >> Contact:sip:alice@atlanta.com; > >> Contact:audio;duplex=3Dfull; > >> Contact:video;duplex=3Drecieve-only; > >> > >> Thanks > >> Mahesh > >> ----- Original Message ----- > >> From: "Mahesh Anjanappa" > >> To: "Paul Kyzivat" > >> Cc: ; "Christer Holmberg" > >> > >> Sent: Wednesday, January 09, 2008 10:48 PM > >> Subject: Re: [Sip] Question on RFC3840/3841 > >> > >> > >> > Thanks Paul. > >> > So would it be right if i have a Contact Headers describing > >> Duplex Audio & > >> > one-way Video Capabilities as follows? > >> > > >> > Contact:sip:alice@atlanta.com; > >> > Contact:sip:audio;duplex=3Dfull; > >> > Contact:sip:video;duplex=3Drecieve-only; > >> > > >> > NOTE: The Predicate(for above) for which i'm attempting is > >> > & ( & (sip.audio) (sip.duplex=3Dfull) ) > >> > ( & (sip.video) (sip.duplex=3Dreceive-only) ) > >> > > >> > regards > >> > Mahesh > >> > > >> > ----- Original Message ----- > From: "Paul Kyzivat"=20 > >> > >> > To: "Mahesh Anjanappa" > >> > Cc: "Christer Holmberg" ; > >> > >> > Sent: Wednesday, January 09, 2008 7:55 PM > >> > Subject: Re: [Sip] Question on RFC3840/3841 > >> > > >> > > >> >> > >> >> > >> >> Mahesh Anjanappa wrote: > >> >>> hi > >> >>> That is my understanding as well. But if that is the case > >> then it should > >> >>> apply to Contact header as well > >> >>> when describing Capabilities using Feature parameters in > >> Contact Header. > >> >>> But i'm not sure if it applies the same way. I had posted > >> this question > >> >>> long ago but didnt get any comments on it. > >> >> > >> >> The rule forbidding multiple instances of a parameter > >> applies to all > >> >> headers, so it applies to Contact. E.g. the following=20 > is illegal: > >> >> > >> >> = Contact:sip:alice@atlanta.com;methods=3D"INVITE";methods=3D"CANCEL" > >> >> > >> >> Paul > >> > > >> > > >> > > >> > _______________________________________________ > >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current sip > >> > Use sipping@ietf.org for new developments on the=20 > application of sip > >> > >> > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 10 10:03:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCywW-0008B8-3E; Thu, 10 Jan 2008 10:03:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCywV-0008B1-40 for sip-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 10:03:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCywU-0008As-QR for sip@ietf.org; Thu, 10 Jan 2008 10:03:38 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCywT-0000Gu-Vl for sip@ietf.org; Thu, 10 Jan 2008 10:03:38 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2008 10:03:38 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0AF3bXs026778; Thu, 10 Jan 2008 10:03:37 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0AF3apm000195; Thu, 10 Jan 2008 15:03:37 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:03:31 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:03:31 -0500 Message-ID: <478633C4.2060209@cisco.com> Date: Thu, 10 Jan 2008 10:03:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] Question on RFC3840/3841 References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> <478629C1.5090404@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2008 15:03:31.0228 (UTC) FILETIME=[F6976DC0:01C85399] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7004; t=1199977417; x=1200841417; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20RFC3840/3841 |Sender:=20 |To:=20Christer=20Holmberg=20; bh=VRixJtkjER1G7ZYldFVCO7dTp0CdjNlgJNw88ZPEnec=; b=XkPRt83wpKT9NYlDLwQrCuL8KajkuTDlfQvGkqiMdfE5IgHy34THrRcSF6 k+vdWPRieGIuJAw87FK7c+6mSti4KZExlZsuUov5PXnUjrU97C0Ry0rLW52E n32t9HaTst; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, RFC3840 by itself, without 2533, is *not* sufficient to understand how to do the matching. I put an appendix in RFC 4596 that gives an algorithm without reference to 2533. I *think* it is right, but of course it is not normative. Note that IMO none of this is intuitive or straightforward. Every time I get a detailed question on it I have to do a bunch of review before I can answer it. (But maybe that's just because I don't have enough neurons left.) Paul Christer Holmberg wrote: > Paul, > > Regarding the matching, are you saying that reading RFC3840 is enough to > understand how the matching is done in a "SIP environment"? Or, do I > also need to read RFC2533? > > I have some questions on the matching, but I will come back to them > later. I still have some reading to do. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 10. tammikuuta 2008 16:21 >> To: Mahesh Anjanappa >> Cc: Christer Holmberg; sip@ietf.org >> Subject: Re: [Sip] Question on RFC3840/3841 >> >> >> >> Mahesh Anjanappa wrote: >>> Yes the ';' is a mistake. But i'm not sure if each Contact should >>> contain "alice@atlanta.com" >> Well, it has to have a URI to be syntactically correct. >> >> Your problem is that you are trying to express something that >> cannot be expressed with the callee caps syntax. It only maps >> to a subset of the syntax supported by RFC 2533. >> >>> because the predicate that i'm trying to represent is as follows >>> meanig to say alice supports a communication which whose >> capability is >>> Duplex Audio + One Way Video. >> You just can't say that. Sorry. >> >> A little history may help you to understand, though it won't >> solve your >> problem: >> >> The initial draft for callerprefs came out a very long time >> ago. (The earliest draft I have is -03 which came out in >> november of 2000.) It set the basic syntax and the initial >> set of capabilities. >> >> It was however very weak on the semantics of matching. I >> eventually got involved because I was interested in it and >> identified many of the semantic issues. Jonathan and I worked >> on it for a long time. >> Eventually, because of some review comments I think, Jonathan >> tried to define the semantics using RFC 2533 because it was a >> standard that seemed to be at least partially suitable to the >> task. (In retrospect this may not have been such a good idea, >> since it adds an additional layer of complexity.) >> >> RFC 2533 syntax is much richer. But it was not a goal to >> provide that richness. (Mapping that all onto SIP header >> syntax would be awful.) It was only used as an intermediate >> form to define the semantics of the SIP headers. >> >> Its understood that there are lots of things one might want >> to express that you can't express. >> >> If you aren't already aware of it, you might want to look at >> RFC 4596 (Guidelines for Usage of the Session Initiation >> Protocol (SIP) Caller Preferences Extension). >> >> Paul >> >>> If each of the COntact contains alice@atlanta.com wouldnt it be >>> interpreted as " alice supports duplex audio and oneway video >>> separatley and not both at the same time". >>> Actually i'm not quite sure how to represesnt the predicate in the >>> Contact header correctly, hence my Queries. It all stems from the >>> statement which you too noted " There MUST only be one >> instance of any >>> feature tag in feature-param." in RFC 3840 >>> >>> >>> Predicate: >>> ------------ >>> & ( & (sip.audio) (sip.duplex=full) ) >>> ( & (sip.video) (sip.duplex=receive-only) ) >>> >>> regards >>> Mahesh >>> ----- Original Message ----- From: "Christer Holmberg" >>> >>> To: "Mahesh Anjanappa" ; "Paul Kyzivat" >>> >>> Cc: >>> Sent: Thursday, January 10, 2008 11:30 AM >>> Subject: RE: [Sip] Question on RFC3840/3841 >>> >>> >>> >>> Shouldn't each Contact also contain "alice@atlanta.com"? >>> >>> Also, why do you have ";" at the end of each Contact? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Mahesh Anjanappa [mailto:mahesha@samsung.com] >>>> Sent: 10. tammikuuta 2008 6:16 >>>> To: Paul Kyzivat >>>> Cc: sip@ietf.org; Christer Holmberg >>>> Subject: Re: [Sip] Question on RFC3840/3841 >>>> >>>> hi Paul, >>>> Sorry there is a mistake in Contact header i >>>> described.Following is what i wanted to: >>>> Contact:sip:alice@atlanta.com; >>>> Contact:audio;duplex=full; >>>> Contact:video;duplex=recieve-only; >>>> >>>> Thanks >>>> Mahesh >>>> ----- Original Message ----- >>>> From: "Mahesh Anjanappa" >>>> To: "Paul Kyzivat" >>>> Cc: ; "Christer Holmberg" >>>> >>>> Sent: Wednesday, January 09, 2008 10:48 PM >>>> Subject: Re: [Sip] Question on RFC3840/3841 >>>> >>>> >>>>> Thanks Paul. >>>>> So would it be right if i have a Contact Headers describing >>>> Duplex Audio & >>>>> one-way Video Capabilities as follows? >>>>> >>>>> Contact:sip:alice@atlanta.com; >>>>> Contact:sip:audio;duplex=full; >>>>> Contact:sip:video;duplex=recieve-only; >>>>> >>>>> NOTE: The Predicate(for above) for which i'm attempting is >>>>> & ( & (sip.audio) (sip.duplex=full) ) >>>>> ( & (sip.video) (sip.duplex=receive-only) ) >>>>> >>>>> regards >>>>> Mahesh >>>>> >>>>> ----- Original Message ----- > From: "Paul Kyzivat" >>>> >>>>> To: "Mahesh Anjanappa" >>>>> Cc: "Christer Holmberg" ; >>>> >>>>> Sent: Wednesday, January 09, 2008 7:55 PM >>>>> Subject: Re: [Sip] Question on RFC3840/3841 >>>>> >>>>> >>>>>> >>>>>> Mahesh Anjanappa wrote: >>>>>>> hi >>>>>>> That is my understanding as well. But if that is the case >>>> then it should >>>>>>> apply to Contact header as well >>>>>>> when describing Capabilities using Feature parameters in >>>> Contact Header. >>>>>>> But i'm not sure if it applies the same way. I had posted >>>> this question >>>>>>> long ago but didnt get any comments on it. >>>>>> The rule forbidding multiple instances of a parameter >>>> applies to all >>>>>> headers, so it applies to Contact. E.g. the following >> is illegal: >>>>>> Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL" >>>>>> >>>>>> Paul >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 08:54:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKL0-0004Rm-Vd; Fri, 11 Jan 2008 08:54:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDKKz-0004Rf-A4 for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 08:54:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKKy-0004RX-VQ for sip@ietf.org; Fri, 11 Jan 2008 08:54:21 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDKKy-0007eU-A8 for sip@ietf.org; Fri, 11 Jan 2008 08:54:20 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6AF4121665; Fri, 11 Jan 2008 14:54:19 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-67-4787750ba8cc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3525D2175B; Fri, 11 Jan 2008 14:54:19 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:54:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 14:54:17 +0100 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: Acg2ih6i4UTKPgVSQf2WFbiy3Qsq9wcUuLeAAFMOArA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 11 Jan 2008 13:54:18.0935 (UTC) FILETIME=[760B8C70:01C85459] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, We have submitted a draft with an alternative proposal. It can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-del ivery-00.txt Regards, Christer =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 9. tammikuuta 2008 18:32 > To: sip@ietf.org > Subject: [Sip] RE: Delivering request-URI and parameters to=20 > UAS via proxy >=20 > A reminder of the deadline on the 11th January for submitting=20 > alternative proposals on the way forward. >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: Tuesday, December 04, 2007 3:27 PM > > To: sip@ietf.org > > Subject: Delivering request-URI and parameters to UAS via proxy > >=20 > > (As WG chair) > >=20 > > We have a couple of milestones that we generated as a result of=20 > > discussion of > >=20 > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > se-route-01.txt > >=20 > > Dec 2007 Delivering request-URI and parameters to UAS via=20 > > proxy to WGLC =20 > > Feb 2008 Delivering request-URI and parameters to UAS via=20 > > proxy to IESG (PS) > >=20 > > This work is currently stalled and the editor needs input. > >=20 > > The document contains various example scenarios where a solution is=20 > > required, for which there appears to be no dispute that a=20 > solution is=20 > > needed. > >=20 > > The document proposes one solution to resolve these example=20 > scenarios,=20 > > but this solution is not gaining consensus. At least one other=20 > > solution has been talked about, but there is no=20 > documentation on the=20 > > table. > >=20 > > This mail is to identify a deadline for other solutions to=20 > the example=20 > > scenarios to be documented as internet drafts, showing how the=20 > > solution works for those scenarios. This deadline is: > >=20 > > January 11th 2008 > >=20 > > It is appropriate fo these documents to identify any other=20 > scenarios=20 > > where such a solution is appropriate. Any other input is=20 > also welcome=20 > > in identifying other scenarios. > >=20 > > If we have no such internet-drafts by this deadline, we=20 > will proceed=20 > > with completing the solution we have. > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 10:28:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDLoE-0003di-4d; Fri, 11 Jan 2008 10:28:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDLoC-0003cS-B9 for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 10:28:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDLoB-0003c9-VQ for sip@ietf.org; Fri, 11 Jan 2008 10:28:36 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDLoB-0001OA-Cn for sip@ietf.org; Fri, 11 Jan 2008 10:28:35 -0500 X-IronPort-AV: E=Sophos;i="4.24,272,1196658000"; d="scan'208";a="83052174" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2008 10:28:32 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0BFSV6R024859; Fri, 11 Jan 2008 10:28:31 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0BFSL7P013060; Fri, 11 Jan 2008 15:28:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 10:28:28 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 10:28:28 -0500 Message-ID: <47878B1E.3010303@cisco.com> Date: Fri, 11 Jan 2008 10:28:30 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2008 15:28:28.0455 (UTC) FILETIME=[9D6BE370:01C85466] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3813; t=1200065311; x=1200929311; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Delivering=20request-UR I=20and=20parameters=20to=20UAS=20via=20proxy |Sender:=20 |To:=20Christer=20Holmberg=20; bh=CMDUEvwqFuNDUc675ayzyr3qihS3zulYf/iNfAyaw0Y=; b=NgobFzsvupFxuT1yWJw4UotZHo0b7a4Bnydmw3l0CYNR/PSGQHgVd7djki RFuUrBJ/rxN0PbwV4un6B55vy7uJkFzRay8WpvIFuxpTkYLKbMlP6R2+BNzZ 5FWH357URo; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, I have some questions and comments: - I don't understand your examples in section 3. They are a bit sketchy about the assumptions they are making, and in notation. I get lost about which referenced component has which address, etc. I am far from convinced that these are problems with appropriate use of the mechanism. - It seems from your analysis of use cases that it is P-Called-Party that solves many of them, not Target. So both headers seem to be part of the solution. Its not entirely clear to me at the moment whether the R-URI in the loose-route approach aligns with Target or P-Called-Party. Since they are different, it can't align with both. So there must be some features it doesn't cover. I haven't fully grokked that yet. Paul Christer Holmberg wrote: > Hi, > > We have submitted a draft with an alternative proposal. > > It can also be found at: > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-del > ivery-00.txt > > Regards, > > Christer > > > >> -----Original Message----- >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> Sent: 9. tammikuuta 2008 18:32 >> To: sip@ietf.org >> Subject: [Sip] RE: Delivering request-URI and parameters to >> UAS via proxy >> >> A reminder of the deadline on the 11th January for submitting >> alternative proposals on the way forward. >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: DRAGE, Keith (Keith) >>> Sent: Tuesday, December 04, 2007 3:27 PM >>> To: sip@ietf.org >>> Subject: Delivering request-URI and parameters to UAS via proxy >>> >>> (As WG chair) >>> >>> We have a couple of milestones that we generated as a result of >>> discussion of >>> >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo >>> se-route-01.txt >>> >>> Dec 2007 Delivering request-URI and parameters to UAS via >>> proxy to WGLC >>> Feb 2008 Delivering request-URI and parameters to UAS via >>> proxy to IESG (PS) >>> >>> This work is currently stalled and the editor needs input. >>> >>> The document contains various example scenarios where a solution is >>> required, for which there appears to be no dispute that a >> solution is >>> needed. >>> >>> The document proposes one solution to resolve these example >> scenarios, >>> but this solution is not gaining consensus. At least one other >>> solution has been talked about, but there is no >> documentation on the >>> table. >>> >>> This mail is to identify a deadline for other solutions to >> the example >>> scenarios to be documented as internet drafts, showing how the >>> solution works for those scenarios. This deadline is: >>> >>> January 11th 2008 >>> >>> It is appropriate fo these documents to identify any other >> scenarios >>> where such a solution is appropriate. Any other input is >> also welcome >>> in identifying other scenarios. >>> >>> If we have no such internet-drafts by this deadline, we >> will proceed >>> with completing the solution we have. >>> >>> >>> Regards >>> >>> Keith >>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 12:01:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNG6-0008FN-V8; Fri, 11 Jan 2008 12:01:30 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDNG5-00088z-Au for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 12:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNG5-00088r-0e for sip@ietf.org; Fri, 11 Jan 2008 12:01:29 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDNG2-0000o2-3s for sip@ietf.org; Fri, 11 Jan 2008 12:01:29 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUH00F5MOM8O6@siemenscomms.co.uk> for sip@ietf.org; Fri, 11 Jan 2008 17:01:23 +0000 (GMT) Date: Fri, 11 Jan 2008 17:01:21 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy In-reply-to: <47878B1E.3010303@cisco.com> To: Paul Kyzivat , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy thread-index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, In addition to Paul's concerns, I am having difficulty understanding why the To header field is insufficient for the cases where the Target header field is proposed. The initial source of this confusion was the statement "the Target header field represents the initial target identity that was used to initiate a session to the target" So we now have 4 fields (ignoring Route): - To - Target - P-Called-ID - Request-URI I think it would benefit from a clearer exposition of the semantics and relationship between these. John =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 11 January 2008 15:29 > To: Christer Holmberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: Re: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy >=20 > Christer, >=20 > I have some questions and comments: >=20 > - I don't understand your examples in section 3. They are a=20 > bit sketchy=20 > about the assumptions they are making, and in notation. I get=20 > lost about=20 > which referenced component has which address, etc. I am far from=20 > convinced that these are problems with appropriate use of the=20 > mechanism. >=20 > - It seems from your analysis of use cases that it is P-Called-Party=20 > that solves many of them, not Target. So both headers seem to=20 > be part of=20 > the solution. Its not entirely clear to me at the moment whether the=20 > R-URI in the loose-route approach aligns with Target or=20 > P-Called-Party.=20 > Since they are different, it can't align with both. So there must be=20 > some features it doesn't cover. I haven't fully grokked that yet. >=20 > Paul >=20 >=20 > Christer Holmberg wrote: > > Hi, > >=20 > > We have submitted a draft with an alternative proposal. > >=20 > > It can also be found at: > >=20 > >=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > et-uri-del > > ivery-00.txt > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > >> Sent: 9. tammikuuta 2008 18:32 > >> To: sip@ietf.org > >> Subject: [Sip] RE: Delivering request-URI and parameters to=20 > >> UAS via proxy > >> > >> A reminder of the deadline on the 11th January for submitting=20 > >> alternative proposals on the way forward. > >> > >> Regards > >> > >> Keith=20 > >> > >>> -----Original Message----- > >>> From: DRAGE, Keith (Keith) > >>> Sent: Tuesday, December 04, 2007 3:27 PM > >>> To: sip@ietf.org > >>> Subject: Delivering request-URI and parameters to UAS via proxy > >>> > >>> (As WG chair) > >>> > >>> We have a couple of milestones that we generated as a result of=20 > >>> discussion of > >>> > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > >>> se-route-01.txt > >>> > >>> Dec 2007 Delivering request-URI and parameters to UAS via=20 > >>> proxy to WGLC =20 > >>> Feb 2008 Delivering request-URI and parameters to UAS via=20 > >>> proxy to IESG (PS) > >>> > >>> This work is currently stalled and the editor needs input. > >>> > >>> The document contains various example scenarios where a=20 > solution is=20 > >>> required, for which there appears to be no dispute that a=20 > >> solution is=20 > >>> needed. > >>> > >>> The document proposes one solution to resolve these example=20 > >> scenarios,=20 > >>> but this solution is not gaining consensus. At least one other=20 > >>> solution has been talked about, but there is no=20 > >> documentation on the=20 > >>> table. > >>> > >>> This mail is to identify a deadline for other solutions to=20 > >> the example=20 > >>> scenarios to be documented as internet drafts, showing how the=20 > >>> solution works for those scenarios. This deadline is: > >>> > >>> January 11th 2008 > >>> > >>> It is appropriate fo these documents to identify any other=20 > >> scenarios=20 > >>> where such a solution is appropriate. Any other input is=20 > >> also welcome=20 > >>> in identifying other scenarios. > >>> > >>> If we have no such internet-drafts by this deadline, we=20 > >> will proceed=20 > >>> with completing the solution we have. > >>> > >>> > >>> Regards > >>> > >>> Keith > >>> > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip=20 > >> Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 13:58:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDP53-0001NJ-Q4; Fri, 11 Jan 2008 13:58:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDP52-0001N9-4Q for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 13:58:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDP51-0001N0-Oq for sip@ietf.org; Fri, 11 Jan 2008 13:58:11 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDP51-0008OW-0T for sip@ietf.org; Fri, 11 Jan 2008 13:58:11 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m0BIsSK27246; Fri, 11 Jan 2008 18:54:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 12:58:04 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3A= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Christer Holmberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: sip@ietf.org, "Elwell, John" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm also totally confused now about what is being proposed. The Target seems identical to the To header field. I tought that what you (Christer) was arguing for is using the = P-Called-Header instead of the new loose route proposal, i.e., not for the "initial = target", but for the "current target". =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Friday, January 11, 2008 09:01 > To: Paul Kyzivat; Christer Holmberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy >=20 > Christer, >=20 > In addition to Paul's concerns, I am having difficulty=20 > understanding why the To header field is insufficient for the=20 > cases where the Target header field is proposed. The initial=20 > source of this confusion was the statement "the Target header=20 > field represents > the initial target identity that was used to initiate a session to > the target" >=20 > So we now have 4 fields (ignoring Route): > - To > - Target > - P-Called-ID > - Request-URI > I think it would benefit from a clearer exposition of the=20 > semantics and relationship between these. >=20 > John >=20 > =20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 11 January 2008 15:29 > > To: Christer Holmberg > > Cc: sip@ietf.org; DRAGE, Keith (Keith) > > Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS=20 > > via proxy > >=20 > > Christer, > >=20 > > I have some questions and comments: > >=20 > > - I don't understand your examples in section 3. They are a bit=20 > > sketchy about the assumptions they are making, and in=20 > notation. I get=20 > > lost about which referenced component has which address,=20 > etc. I am far=20 > > from convinced that these are problems with appropriate use of the=20 > > mechanism. > >=20 > > - It seems from your analysis of use cases that it is=20 > P-Called-Party=20 > > that solves many of them, not Target. So both headers seem=20 > to be part=20 > > of the solution. Its not entirely clear to me at the moment whether=20 > > the R-URI in the loose-route approach aligns with Target or=20 > > P-Called-Party. > > Since they are different, it can't align with both. So=20 > there must be=20 > > some features it doesn't cover. I haven't fully grokked that yet. > >=20 > > Paul > >=20 > >=20 > > Christer Holmberg wrote: > > > Hi, > > >=20 > > > We have submitted a draft with an alternative proposal. > > >=20 > > > It can also be found at: > > >=20 > > >=20 > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > et-uri-del > > > ivery-00.txt > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > =20 > > >=20 > > >> -----Original Message----- > > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > >> Sent: 9. tammikuuta 2008 18:32 > > >> To: sip@ietf.org > > >> Subject: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via=20 > > >> proxy > > >> > > >> A reminder of the deadline on the 11th January for submitting=20 > > >> alternative proposals on the way forward. > > >> > > >> Regards > > >> > > >> Keith > > >> > > >>> -----Original Message----- > > >>> From: DRAGE, Keith (Keith) > > >>> Sent: Tuesday, December 04, 2007 3:27 PM > > >>> To: sip@ietf.org > > >>> Subject: Delivering request-URI and parameters to UAS via proxy > > >>> > > >>> (As WG chair) > > >>> > > >>> We have a couple of milestones that we generated as a result of=20 > > >>> discussion of > > >>> > > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > >>> se-route-01.txt > > >>> > > >>> Dec 2007 Delivering request-URI and parameters to UAS via=20 > > >>> proxy to WGLC =20 > > >>> Feb 2008 Delivering request-URI and parameters to UAS via=20 > > >>> proxy to IESG (PS) > > >>> > > >>> This work is currently stalled and the editor needs input. > > >>> > > >>> The document contains various example scenarios where a > > solution is > > >>> required, for which there appears to be no dispute that a > > >> solution is > > >>> needed. > > >>> > > >>> The document proposes one solution to resolve these example > > >> scenarios, > > >>> but this solution is not gaining consensus. At least one other=20 > > >>> solution has been talked about, but there is no > > >> documentation on the > > >>> table. > > >>> > > >>> This mail is to identify a deadline for other solutions to > > >> the example > > >>> scenarios to be documented as internet drafts, showing how the=20 > > >>> solution works for those scenarios. This deadline is: > > >>> > > >>> January 11th 2008 > > >>> > > >>> It is appropriate fo these documents to identify any other > > >> scenarios > > >>> where such a solution is appropriate. Any other input is > > >> also welcome > > >>> in identifying other scenarios. > > >>> > > >>> If we have no such internet-drafts by this deadline, we > > >> will proceed > > >>> with completing the solution we have. > > >>> > > >>> > > >>> Regards > > >>> > > >>> Keith > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use=20 > > >> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 14:21:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPRp-0001DD-7S; Fri, 11 Jan 2008 14:21:45 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDPRo-0001D4-Jz for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:21:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPRo-0001Cs-8w for sip@ietf.org; Fri, 11 Jan 2008 14:21:44 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDPRn-0000id-Ah for sip@ietf.org; Fri, 11 Jan 2008 14:21:44 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BB95720573; Fri, 11 Jan 2008 20:20:24 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-71-4787c1788125 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 90A442048F; Fri, 11 Jan 2008 20:20:24 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 20:20:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 20:20:22 +0100 Message-ID: In-Reply-To: <47878B1E.3010303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZqppRZgNVlfARoeWtFak56jdIAAHerXg References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Jan 2008 19:20:24.0390 (UTC) FILETIME=[03F70E60:01C85487] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul,=20 >I have some questions and comments: >=20 >- I don't understand your examples in section 3. They are a=20 >bit sketchy about the assumptions they are making, and in=20 >notation. I get lost about which referenced component has=20 >which address, etc. I am far from convinced that these are=20 >problems with appropriate use of the mechanism. As indicated in chapter 3, one of the main issues/limitations with the J'draft solution is that the entity wanting to use it must have knowledge whether the next hop also supports it. My understanding from off-line discussions I had with Jonathan in Vancouver is also that Jonathan agrees to that issue/limitation. The purpose of the examples is just to show what can go wrong if the next hop does not understand the mechanism. But, if we all agree to the limitation with the J'draft solution I don't know whether we need to spend too much time on the examples. >- It seems from your analysis of use cases that it is=20 >P-Called-Party that solves many of them, not Target. So both=20 >headers seem to be part of the solution. No, as far as the alternative to the J'draft solution is concerned, the alternative is Target. We believe it can be used for all listed use-cases. Since I myself have been talking about P-CPI as an alternative, we wanted to show in which cases it could be used as an alternative, and why we think that P-CPI still would have to be used in IMS.=20 But, we have realized that P-CPI as defined and used today probably would not solve all the use-cases, and that is the reason we came up with the Target header. >Its not entirely clear to me at the moment whether the R-URI in the=20 >loose-route approach aligns with Target or P-Called-Party.=20 >Since they are different, it can't align with both. So there=20 >must be some features it doesn't cover. I haven't fully=20 >grokked that yet. I appologize if the P-CPI text causes confusion. Again, the alternative to the J'draft solution we propose is Target. Regards, Christer > Christer Holmberg wrote: > > Hi, > >=20 > > We have submitted a draft with an alternative proposal. > >=20 > > It can also be found at: > >=20 > >=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-d > > el > > ivery-00.txt > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> Sent: 9. tammikuuta 2008 18:32 > >> To: sip@ietf.org > >> Subject: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via=20 > >> proxy > >> > >> A reminder of the deadline on the 11th January for submitting=20 > >> alternative proposals on the way forward. > >> > >> Regards > >> > >> Keith > >> > >>> -----Original Message----- > >>> From: DRAGE, Keith (Keith) > >>> Sent: Tuesday, December 04, 2007 3:27 PM > >>> To: sip@ietf.org > >>> Subject: Delivering request-URI and parameters to UAS via proxy > >>> > >>> (As WG chair) > >>> > >>> We have a couple of milestones that we generated as a result of=20 > >>> discussion of > >>> > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > >>> se-route-01.txt > >>> > >>> Dec 2007 Delivering request-URI and parameters to UAS via=20 > >>> proxy to WGLC =20 > >>> Feb 2008 Delivering request-URI and parameters to UAS via=20 > >>> proxy to IESG (PS) > >>> > >>> This work is currently stalled and the editor needs input. > >>> > >>> The document contains various example scenarios where a=20 > solution is=20 > >>> required, for which there appears to be no dispute that a > >> solution is > >>> needed. > >>> > >>> The document proposes one solution to resolve these example > >> scenarios, > >>> but this solution is not gaining consensus. At least one other=20 > >>> solution has been talked about, but there is no > >> documentation on the > >>> table. > >>> > >>> This mail is to identify a deadline for other solutions to > >> the example > >>> scenarios to be documented as internet drafts, showing how the=20 > >>> solution works for those scenarios. This deadline is: > >>> > >>> January 11th 2008 > >>> > >>> It is appropriate fo these documents to identify any other > >> scenarios > >>> where such a solution is appropriate. Any other input is > >> also welcome > >>> in identifying other scenarios. > >>> > >>> If we have no such internet-drafts by this deadline, we > >> will proceed > >>> with completing the solution we have. > >>> > >>> > >>> Regards > >>> > >>> Keith > >>> > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 14:33:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPcy-00006Z-LU; Fri, 11 Jan 2008 14:33:16 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDPcx-0008MS-2K for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:33:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPcw-0008K8-MW for sip@ietf.org; Fri, 11 Jan 2008 14:33:14 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDPcv-00017v-Eg for sip@ietf.org; Fri, 11 Jan 2008 14:33:14 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C96C92053E; Fri, 11 Jan 2008 20:33:12 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-98-4787c478d9f7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F732200D8; Fri, 11 Jan 2008 20:33:12 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 20:33:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 20:33:11 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsA== References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" X-OriginalArrivalTime: 11 Jan 2008 19:33:12.0307 (UTC) FILETIME=[CDADE430:01C85488] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Paul Kyzivat , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I answer both John's and Francois' questions in this reply. >I'm also totally confused now about what is being proposed. >=20 >The Target seems identical to the To header field. I don't think they are identical. Jonathan's draft describes the issues with using the To header. >I tought that what you (Christer) was arguing for is using=20 >the P-Called-Header instead of the new loose route proposal,=20 >i.e., not for the "initial target", but for the "current target". Yes, I have. But, as the P-PCI header is currently defined and used (e.g. in 3GPP) we are not sure it could be used for all use-cases. Also, if you read the abstract it does say "current target". I guess the same wording should be used elsewhere too. >>In addition to Paul's concerns, I am having difficulty understanding=20 >>why the To header field is insufficient for the cases where the Target >>header field is proposed. The initial source of this confusion was the >>statement "the Target header field represents the initial target identity that was used to initiate a=20 >>session to the target" >>=20 >>So we now have 4 fields (ignoring Route): >>- To >>- Target >>- P-Called-ID >>- Request-URI >>I think it would benefit from a clearer exposition of the semantics=20 >>and relationship between these. That main purpose of the document was to define an alternative to the solution in Jonathan's draft, and due to time issues that is what we focused on. But, I do agree that there are lots of things that could be clarified and explained - no matter what solution we move forward with. Regards, Christer > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 11 January 2008 15:29 > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DRAGE, Keith (Keith) > > > Subject: Re: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > > > via proxy > > >=20 > > > Christer, > > >=20 > > > I have some questions and comments: > > >=20 > > > - I don't understand your examples in section 3. They are a bit=20 > > > sketchy about the assumptions they are making, and in > > notation. I get > > > lost about which referenced component has which address, > > etc. I am far > > > from convinced that these are problems with appropriate=20 > use of the=20 > > > mechanism. > > >=20 > > > - It seems from your analysis of use cases that it is > > P-Called-Party > > > that solves many of them, not Target. So both headers seem > > to be part > > > of the solution. Its not entirely clear to me at the=20 > moment whether=20 > > > the R-URI in the loose-route approach aligns with Target or=20 > > > P-Called-Party. > > > Since they are different, it can't align with both. So > > there must be > > > some features it doesn't cover. I haven't fully grokked that yet. > > >=20 > > > Paul > > >=20 > > >=20 > > > Christer Holmberg wrote: > > > > Hi, > > > >=20 > > > > We have submitted a draft with an alternative proposal. > > > >=20 > > > > It can also be found at: > > > >=20 > > > >=20 > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > et-uri-del > > > > ivery-00.txt > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > =20 > > > >=20 > > > >> -----Original Message----- > > > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > >> Sent: 9. tammikuuta 2008 18:32 > > > >> To: sip@ietf.org > > > >> Subject: [Sip] RE: Delivering request-URI and parameters > > to UAS via > > > >> proxy > > > >> > > > >> A reminder of the deadline on the 11th January for submitting=20 > > > >> alternative proposals on the way forward. > > > >> > > > >> Regards > > > >> > > > >> Keith > > > >> > > > >>> -----Original Message----- > > > >>> From: DRAGE, Keith (Keith) > > > >>> Sent: Tuesday, December 04, 2007 3:27 PM > > > >>> To: sip@ietf.org > > > >>> Subject: Delivering request-URI and parameters to UAS=20 > via proxy > > > >>> > > > >>> (As WG chair) > > > >>> > > > >>> We have a couple of milestones that we generated as a=20 > result of=20 > > > >>> discussion of > > > >>> > > > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > >>> se-route-01.txt > > > >>> > > > >>> Dec 2007 Delivering request-URI and parameters to UAS via=20 > > > >>> proxy to WGLC =20 > > > >>> Feb 2008 Delivering request-URI and parameters to UAS via=20 > > > >>> proxy to IESG (PS) > > > >>> > > > >>> This work is currently stalled and the editor needs input. > > > >>> > > > >>> The document contains various example scenarios where a > > > solution is > > > >>> required, for which there appears to be no dispute that a > > > >> solution is > > > >>> needed. > > > >>> > > > >>> The document proposes one solution to resolve these example > > > >> scenarios, > > > >>> but this solution is not gaining consensus. At least=20 > one other=20 > > > >>> solution has been talked about, but there is no > > > >> documentation on the > > > >>> table. > > > >>> > > > >>> This mail is to identify a deadline for other solutions to > > > >> the example > > > >>> scenarios to be documented as internet drafts,=20 > showing how the=20 > > > >>> solution works for those scenarios. This deadline is: > > > >>> > > > >>> January 11th 2008 > > > >>> > > > >>> It is appropriate fo these documents to identify any other > > > >> scenarios > > > >>> where such a solution is appropriate. Any other input is > > > >> also welcome > > > >>> in identifying other scenarios. > > > >>> > > > >>> If we have no such internet-drafts by this deadline, we > > > >> will proceed > > > >>> with completing the solution we have. > > > >>> > > > >>> > > > >>> Regards > > > >>> > > > >>> Keith > > > >>> > > > >>> > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol Use=20 > > > >> sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > >> sipping@ietf.org for new developments on the application of sip > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 14:37:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPh0-0003ik-P2; Fri, 11 Jan 2008 14:37:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDPgy-0003if-UJ for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:37:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPgy-0003iX-KX for sip@ietf.org; Fri, 11 Jan 2008 14:37:24 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDPgx-0003q9-S6 for sip@ietf.org; Fri, 11 Jan 2008 14:37:24 -0500 X-IronPort-AV: E=Sophos;i="4.24,273,1196658000"; d="scan'208";a="83084433" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2008 14:37:24 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0BJbN7H004628; Fri, 11 Jan 2008 14:37:23 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0BJbJ6p000928; Fri, 11 Jan 2008 19:37:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:37:16 -0500 Received: from [161.44.183.181] ([161.44.183.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:37:16 -0500 Message-ID: <4787C56B.9050002@cisco.com> Date: Fri, 11 Jan 2008 14:37:15 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2008 19:37:16.0236 (UTC) FILETIME=[5F1280C0:01C85489] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6048; t=1200080243; x=1200944243; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Delivering=20request-UR I=20and=20parameters=20to=20UAS=20via=20proxy |Sender:=20 |To:=20Christer=20Holmberg=20; bh=a4VhrU9dV+6X/IYTgx2VfaYGqxrUO6SATWVwQAhklxg=; b=ISUC3r10SrNAfvgRW/V+TivwJVi0wHsszDFpjbHi95KhawYQo0nzn8viIH CDh/uXmxrVtQLZLW1ka6DLHVjAwXgBezuxUrNNl6SP8bEBadLEMm8RBxRj0D FojWMHEcxS; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi Paul, > >> I have some questions and comments: >> >> - I don't understand your examples in section 3. They are a >> bit sketchy about the assumptions they are making, and in >> notation. I get lost about which referenced component has >> which address, etc. I am far from convinced that these are >> problems with appropriate use of the mechanism. > > As indicated in chapter 3, one of the main issues/limitations with the > J'draft solution is that the entity wanting to use it must have > knowledge whether the next hop also supports it. My understanding from > off-line discussions I had with Jonathan in Vancouver is also that > Jonathan agrees to that issue/limitation. > > The purpose of the examples is just to show what can go wrong if the > next hop does not understand the mechanism. But, if we all agree to the > limitation with the J'draft solution I don't know whether we need to > spend too much time on the examples. The limitation is the limitation. It means that you don't use the mechanism if you don't know the next hop supports it. So its useless to speculate what would go wrong if you use the mechanism with a next hop that doesn't support it. >> - It seems from your analysis of use cases that it is >> P-Called-Party that solves many of them, not Target. So both >> headers seem to be part of the solution. > > No, as far as the alternative to the J'draft solution is concerned, the > alternative is Target. We believe it can be used for all listed > use-cases. I don't understand. Several of them called for using P-CPI. > Since I myself have been talking about P-CPI as an alternative, we > wanted to show in which cases it could be used as an alternative, and > why we think that P-CPI still would have to be used in IMS. > > But, we have realized that P-CPI as defined and used today probably > would not solve all the use-cases, and that is the reason we came up > with the Target header. > >> Its not entirely clear to me at the moment whether the R-URI in the >> loose-route approach aligns with Target or P-Called-Party. >> Since they are different, it can't align with both. So there >> must be some features it doesn't cover. I haven't fully >> grokked that yet. > > I appologize if the P-CPI text causes confusion. Again, the alternative > to the J'draft solution we propose is Target. > > Regards, > > Christer > > > > > > > > >> Christer Holmberg wrote: >>> Hi, >>> >>> We have submitted a draft with an alternative proposal. >>> >>> It can also be found at: >>> >>> >> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-d >>> el >>> ivery-00.txt >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >>>> Sent: 9. tammikuuta 2008 18:32 >>>> To: sip@ietf.org >>>> Subject: [Sip] RE: Delivering request-URI and parameters >> to UAS via >>>> proxy >>>> >>>> A reminder of the deadline on the 11th January for submitting >>>> alternative proposals on the way forward. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: DRAGE, Keith (Keith) >>>>> Sent: Tuesday, December 04, 2007 3:27 PM >>>>> To: sip@ietf.org >>>>> Subject: Delivering request-URI and parameters to UAS via proxy >>>>> >>>>> (As WG chair) >>>>> >>>>> We have a couple of milestones that we generated as a result of >>>>> discussion of >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo >>>>> se-route-01.txt >>>>> >>>>> Dec 2007 Delivering request-URI and parameters to UAS via >>>>> proxy to WGLC >>>>> Feb 2008 Delivering request-URI and parameters to UAS via >>>>> proxy to IESG (PS) >>>>> >>>>> This work is currently stalled and the editor needs input. >>>>> >>>>> The document contains various example scenarios where a >> solution is >>>>> required, for which there appears to be no dispute that a >>>> solution is >>>>> needed. >>>>> >>>>> The document proposes one solution to resolve these example >>>> scenarios, >>>>> but this solution is not gaining consensus. At least one other >>>>> solution has been talked about, but there is no >>>> documentation on the >>>>> table. >>>>> >>>>> This mail is to identify a deadline for other solutions to >>>> the example >>>>> scenarios to be documented as internet drafts, showing how the >>>>> solution works for those scenarios. This deadline is: >>>>> >>>>> January 11th 2008 >>>>> >>>>> It is appropriate fo these documents to identify any other >>>> scenarios >>>>> where such a solution is appropriate. Any other input is >>>> also welcome >>>>> in identifying other scenarios. >>>>> >>>>> If we have no such internet-drafts by this deadline, we >>>> will proceed >>>>> with completing the solution we have. >>>>> >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@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@cs.columbia.edu for questions on current sip Use >>> sipping@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@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 14:46:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPpH-00032g-03; Fri, 11 Jan 2008 14:45:59 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDPpG-00032b-FV for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 14:45:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDPpG-00032T-59 for sip@ietf.org; Fri, 11 Jan 2008 14:45:58 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDPpF-0001RU-PE for sip@ietf.org; Fri, 11 Jan 2008 14:45:58 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m0BJgFK01241; Fri, 11 Jan 2008 19:42:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 13:45:54 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqg References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Paul Kyzivat , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, January 11, 2008 11:33 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; Elwell, John; Paul Kyzivat; DRAGE,Keith (Keith) > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy > > >The Target seems identical to the To header field. >=20 > I don't think they are identical. Jonathan's draft describes=20 > the issues with using the To header. Well, your description of "Target" in your draft is indentical to the description of the "To" header. What Jonathan describes as limitations of "To" is that it doesn't reflect any "retargeting". I think what you meant by Target was more the "Current" target as = opposed to the Initiatl Target. And if that's the case, then I don't see why it is different from = P-Called-ID (although I might be missing something with what the P-Called_ID is = supposed to be). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 15:02:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDQ57-0000Qv-NS; Fri, 11 Jan 2008 15:02:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDQ55-0000PC-Sk for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 15:02:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDQ55-0000P4-3Z for sip@ietf.org; Fri, 11 Jan 2008 15:02:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDQ53-0004FC-0a for sip@ietf.org; Fri, 11 Jan 2008 15:02:19 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC0AD212AB; Fri, 11 Jan 2008 21:02:15 +0100 (CET) X-AuditID: c1b4fb3e-b16a4bb00000459d-23-4787cb47c288 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8BAC820253; Fri, 11 Jan 2008 21:02:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 21:02:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 21:02:14 +0100 Message-ID: In-Reply-To: <4787C56B.9050002@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUiWfnBwLh8GzUQYCipl+i5qlSwwAAZW1g References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com> <4787C56B.9050002@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Jan 2008 20:02:15.0279 (UTC) FILETIME=[DC924FF0:01C8548C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>I have some questions and comments: >>> >>>- I don't understand your examples in section 3. They are a bit=20 >>>sketchy about the assumptions they are making, and in notation. I get >>>lost about which referenced component has which address, etc. I am=20 >>>far from convinced that these are problems with appropriate use of=20 >>>the mechanism. >>=20 >>As indicated in chapter 3, one of the main issues/limitations with the >>J'draft solution is that the entity wanting to use it must have=20 >>knowledge whether the next hop also supports it. My understanding from >>off-line discussions I had with Jonathan in Vancouver is also that=20 >>Jonathan agrees to that issue/limitation. >>=20 >>The purpose of the examples is just to show what can go wrong if the=20 >>next hop does not understand the mechanism. But, if we all agree to=20 >>the limitation with the J'draft solution I don't know whether we need=20 >>to spend too much time on the examples. >=20 >The limitation is the limitation. It means that you don't use=20 >the mechanism if you don't know the next hop supports it. So=20 >its useless to speculate what would go wrong if you use the=20 >mechanism with a next hop that doesn't support it. We thought it would be good to show some examples, in case people don't understand WHY the limitation is there. >>>- It seems from your analysis of use cases that it is P-Called-Party=20 >>>that solves many of them, not Target. So both headers seem to be part >>>of the solution. >>=20 >>No, as far as the alternative to the J'draft solution is concerned,=20 >>the alternative is Target. We believe it can be used for all listed=20 >>use-cases. >=20 >I don't understand. Several of them called for using P-CPI. No, we say that there are certain use-case we belive the P-CPI was defined to be used for, but we also say that the Target header can be used for those use-cases. Again, the Target header is our proposal for an alternative to the J'draft solution. Regards, Christer > >> Christer Holmberg wrote: > >>> Hi, > >>> > >>> We have submitted a draft with an alternative proposal. > >>> > >>> It can also be found at: > >>> > >>> > >>=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri- > >> d > >>> el > >>> ivery-00.txt > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> =20 > >>> > >>>> -----Original Message----- > >>>> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >>>> Sent: 9. tammikuuta 2008 18:32 > >>>> To: sip@ietf.org > >>>> Subject: [Sip] RE: Delivering request-URI and parameters > >> to UAS via > >>>> proxy > >>>> > >>>> A reminder of the deadline on the 11th January for submitting=20 > >>>> alternative proposals on the way forward. > >>>> > >>>> Regards > >>>> > >>>> Keith > >>>> > >>>>> -----Original Message----- > >>>>> From: DRAGE, Keith (Keith) > >>>>> Sent: Tuesday, December 04, 2007 3:27 PM > >>>>> To: sip@ietf.org > >>>>> Subject: Delivering request-URI and parameters to UAS via proxy > >>>>> > >>>>> (As WG chair) > >>>>> > >>>>> We have a couple of milestones that we generated as a result of=20 > >>>>> discussion of > >>>>> > >>>>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > >>>>> se-route-01.txt > >>>>> > >>>>> Dec 2007 Delivering request-URI and parameters to UAS via=20 > >>>>> proxy to WGLC =20 > >>>>> Feb 2008 Delivering request-URI and parameters to UAS via=20 > >>>>> proxy to IESG (PS) > >>>>> > >>>>> This work is currently stalled and the editor needs input. > >>>>> > >>>>> The document contains various example scenarios where a > >> solution is > >>>>> required, for which there appears to be no dispute that a > >>>> solution is > >>>>> needed. > >>>>> > >>>>> The document proposes one solution to resolve these example > >>>> scenarios, > >>>>> but this solution is not gaining consensus. At least one other=20 > >>>>> solution has been talked about, but there is no > >>>> documentation on the > >>>>> table. > >>>>> > >>>>> This mail is to identify a deadline for other solutions to > >>>> the example > >>>>> scenarios to be documented as internet drafts, showing how the=20 > >>>>> solution works for those scenarios. This deadline is: > >>>>> > >>>>> January 11th 2008 > >>>>> > >>>>> It is appropriate fo these documents to identify any other > >>>> scenarios > >>>>> where such a solution is appropriate. Any other input is > >>>> also welcome > >>>>> in identifying other scenarios. > >>>>> > >>>>> If we have no such internet-drafts by this deadline, we > >>>> will proceed > >>>>> with completing the solution we have. > >>>>> > >>>>> > >>>>> Regards > >>>>> > >>>>> Keith > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@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=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@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=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 11 15:07:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDQA2-0006A3-0z; Fri, 11 Jan 2008 15:07:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDQ9z-00069x-VQ for sip-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 15:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDQ9z-00069p-LO for sip@ietf.org; Fri, 11 Jan 2008 15:07:23 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDQ9x-0004Ki-Vl for sip@ietf.org; Fri, 11 Jan 2008 15:07:23 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0951020909; Fri, 11 Jan 2008 21:07:21 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-6b-4787cc789f5d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 555DB2005D; Fri, 11 Jan 2008 21:07:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 21:07:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Fri, 11 Jan 2008 21:07:17 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAADKgnA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" X-OriginalArrivalTime: 11 Jan 2008 20:07:20.0117 (UTC) FILETIME=[9244E650:01C8548D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, "Elwell, John" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>The Target seems identical to the To header field. >>=20 >>I don't think they are identical. Jonathan's draft describes the=20 >>issues with using the To header. >=20 >Well, your description of "Target" in your draft is=20 >indentical to the description of the "To" header. >=20 >What Jonathan describes as limitations of "To" is that it=20 >doesn't reflect any "retargeting". >=20 >I think what you meant by Target was more the "Current"=20 >target as opposed to the Initiatl Target. Yes, and I think I did say that futher down in my previous reply :) >And if that's the case, then I don't see why it is different=20 >from P-Called-ID (although I might be missing something with=20 >what the P-Called_ID is supposed to be). I will get back to you on this one. I am writing this e-mail from my home machine, so I don't have all the documents etc. Regards, Christer > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jan 12 08:26:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgNO-00077N-Kb; Sat, 12 Jan 2008 08:26:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDgNN-00077H-8c for sip-confirm+ok@megatron.ietf.org; Sat, 12 Jan 2008 08:26:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgNM-000779-VD for sip@ietf.org; Sat, 12 Jan 2008 08:26:16 -0500 Received: from fg-out-1718.google.com ([72.14.220.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDgNM-0000hB-9D for sip@ietf.org; Sat, 12 Jan 2008 08:26:16 -0500 Received: by fg-out-1718.google.com with SMTP id 16so1501089fgg.41 for ; Sat, 12 Jan 2008 05:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=6tGOp5901t+kibUfjAHgprL72HqZR+KtpkjcE9pRWpc=; b=EEP/52qlwhFuHtPuDbVSUB1a4+9bTtNKMbKpoYiszGGOMTV4krcecYFCOSHLrLtW3YWCrX9inAteZwvF0HmjYD168qGRpGboro74qN8lSoJgEPrzF79Nq/BKn3wrkR4G79CYnRvxQM0bRuUxkqLAS0VwYBSJbqQLaJNJeJSAjNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=xvNEqsmFLMkE+ZJ1HGmuV7hAF80PNpsXS/4LcoiuqIqTLA43LiSZh/cog8y8zZ/tkHi3HEszs7I2u2IGuj+vCSctZtL7Za/o0FhRdSuoCL52xTIL/l4mBLdwyPEI2Y/E8huCBQU6TF9yJ2+/bp9FE+/9+J/PUnB9S8x6LRWYwT4= Received: by 10.78.201.2 with SMTP id y2mr4999653huf.56.1200144375185; Sat, 12 Jan 2008 05:26:15 -0800 (PST) Received: by 10.78.107.18 with HTTP; Sat, 12 Jan 2008 05:26:15 -0800 (PST) Message-ID: <7389c8a20801120526s1a4a4ff3k8f0fbd1591f35909@mail.gmail.com> Date: Sat, 12 Jan 2008 11:26:15 -0200 From: "Nadya Zanon" To: "Farnham, Bruce" Subject: Re: [Sip] I am also a beginner with SIP In-Reply-To: <11669E22A15393479F3066E8C3345491041B47E3@SRVMSXMB1.ad.twtelecom.com> MIME-Version: 1.0 References: <11669E22A15393479F3066E8C3345491041B47E3@SRVMSXMB1.ad.twtelecom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0210835636==" Errors-To: sip-bounces@ietf.org --===============0210835636== Content-Type: multipart/alternative; boundary="----=_Part_5064_1766474.1200144375180" ------=_Part_5064_1766474.1200144375180 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Bruce, I think there is no RFC for Q.931 to SIP mapping. For such implementations, the Q-SIG is used as base. Like I'm also a SIP beginner, I can be wrong.... :) Best regards, Nadya Zanon On 1/3/08, Farnham, Bruce wrote: > > Hello, > > I have been looking for some time for an RFC or specification that > details the mapping of SIP to Q.931. Does anyone know if such a > document exists? > > Thanks in advance, > > Bruce Farnham > Time Warner Telecom > The content contained in this electronic message is not intended to > constitute formation of a contract binding TWTC. TWTC will be > contractually bound only upon execution, by an authorized officer, of > a contract including agreed terms and conditions or by express > application of its tariffs. > > This message is intended only for the use of the individual or entity > to which it is addressed. If the reader of this message is not the > intended recipient, or the employee or agent responsible for > delivering the message to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > message is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to > the sender of this E-Mail or by telephone. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_5064_1766474.1200144375180 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello Bruce,
 
I think there is no RFC for Q.931 to SIP mapping. For such implementations, the Q-SIG is used as base.
Like I'm also a SIP beginner,  I can be wrong.... :)
 
Best regards,
 
Nadya Zanon
 
On 1/3/08, Farnham, Bruce <Bruce.Farnham@twtelecom.com> wrote:

Hello,

I have been looking for some time for an RFC or specification that
details the mapping of SIP to Q.931. Does anyone know if such a
document exists?

Thanks in advance,

Bruce Farnham
Time Warner Telecom

The content contained in this electronic message is not intended to
constitute formation of a contract binding TWTC. TWTC will be
contractually bound only upon execution, by an authorized officer, of
a contract including agreed terms and conditions or by express
application of its tariffs.

This message is intended only for the use of the individual or entity
to which it is addressed. If the reader of this message is not the
intended recipient, or the employee or agent responsible for
delivering the message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the sender of this E-Mail or by telephone.

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

------=_Part_5064_1766474.1200144375180-- --===============0210835636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0210835636==-- From sip-bounces@ietf.org Sat Jan 12 08:27:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgOG-0007gU-MB; Sat, 12 Jan 2008 08:27:12 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDgOE-0007gP-QI for sip-confirm+ok@megatron.ietf.org; Sat, 12 Jan 2008 08:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgOE-0007gH-Gd for sip@ietf.org; Sat, 12 Jan 2008 08:27:10 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDgOD-0000hy-Pq for sip@ietf.org; Sat, 12 Jan 2008 08:27:10 -0500 Received: by fg-out-1718.google.com with SMTP id 16so1501331fgg.41 for ; Sat, 12 Jan 2008 05:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=qSmZYyd/oCnTdYR56aj9nDtsqUrlE+VU+WD2wbebAFQ=; b=IwTKZrqfGZr9Fc0ki71Xe1aHGzkhS1mlgl8eDfTDg2vtfiyEEBYm1PUkdznux+zcs3PVP6/kWTXZWVfUDfhQoTUixC6dJ/M8qagpZBPZvy7vaSnT1QL2pOe52CL4f5c4/qPjpLV+4AhrfMiXNQ+/rHScTGjFNjmuUtktg6SbvIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Slc0vvS6Gk2AIO+jw0FwIJbelmW73lXp1D5ccIVGMEp7tltfUsQBcjxs64bGkXrTE3/aUGAzbOxrXvej7/aRX1k/Ym2zMOWXwggA+N+1TYeDWWBF4L8Nd8YAno4Xeo6B3rBci0Q5nXDXy6ycfANSFTiaLI+6jbgNtXSOM8lfFGY= Received: by 10.78.193.5 with SMTP id q5mr5014294huf.30.1200144428621; Sat, 12 Jan 2008 05:27:08 -0800 (PST) Received: by 10.78.107.18 with HTTP; Sat, 12 Jan 2008 05:27:08 -0800 (PST) Message-ID: <7389c8a20801120527t2cf65dd2qd0d3c7992b12b007@mail.gmail.com> Date: Sat, 12 Jan 2008 11:27:08 -0200 From: "Nadya Zanon" To: "Farnham, Bruce" Subject: Re: [Sip] I am also a beginner with SIP In-Reply-To: <7389c8a20801120526s1a4a4ff3k8f0fbd1591f35909@mail.gmail.com> MIME-Version: 1.0 References: <11669E22A15393479F3066E8C3345491041B47E3@SRVMSXMB1.ad.twtelecom.com> <7389c8a20801120526s1a4a4ff3k8f0fbd1591f35909@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0057137744==" Errors-To: sip-bounces@ietf.org --===============0057137744== Content-Type: multipart/alternative; boundary="----=_Part_5066_16228971.1200144428625" ------=_Part_5066_16228971.1200144428625 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Would you like to work in that with me? I'm really interested. Nadya Zanon On 1/12/08, Nadya Zanon wrote: > > Hello Bruce, > > I think there is no RFC for Q.931 to SIP mapping. For such > implementations, the Q-SIG is used as base. > Like I'm also a SIP beginner, I can be wrong.... :) > > Best regards, > > Nadya Zanon > > On 1/3/08, Farnham, Bruce wrote: > > > Hello, > > > > I have been looking for some time for an RFC or specification that > > details the mapping of SIP to Q.931. Does anyone know if such a > > document exists? > > > > Thanks in advance, > > > > Bruce Farnham > > Time Warner Telecom > > The content contained in this electronic message is not intended to > > constitute formation of a contract binding TWTC. TWTC will be > > contractually bound only upon execution, by an authorized officer, of > > a contract including agreed terms and conditions or by express > > application of its tariffs. > > > > This message is intended only for the use of the individual or entity > > to which it is addressed. If the reader of this message is not the > > intended recipient, or the employee or agent responsible for > > delivering the message to the intended recipient, you are hereby > > notified that any dissemination, distribution or copying of this > > message is strictly prohibited. If you have received this > > communication in error, please notify us immediately by replying to > > the sender of this E-Mail or by telephone. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > ------=_Part_5066_16228971.1200144428625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
Would you like to work in that with me?
I'm really interested.
 
Nadya Zanon
 
On 1/12/08, Nadya Zanon <nadya.zanon@gmail.com> wrote:
Hello Bruce,
 
I think there is no RFC for Q.931 to SIP mapping. For such implementations, the Q-SIG is used as base.
Like I'm also a SIP beginner,  I can be wrong.... :)
 
Best regards,
 
Nadya Zanon
 
On 1/3/08, Farnham, Bruce < Bruce.Farnham@twtelecom.com> wrote:

Hello,

I have been looking for some time for an RFC or specification that
details the mapping of SIP to Q.931. Does anyone know if such a
document exists?

Thanks in advance,

Bruce Farnham
Time Warner Telecom

The content contained in this electronic message is not intended to
constitute formation of a contract binding TWTC. TWTC will be
contractually bound only upon execution, by an authorized officer, of
a contract including agreed terms and conditions or by express
application of its tariffs.

This message is intended only for the use of the individual or entity
to which it is addressed. If the reader of this message is not the
intended recipient, or the employee or agent responsible for
delivering the message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the sender of this E-Mail or by telephone.

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


------=_Part_5066_16228971.1200144428625-- --===============0057137744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0057137744==-- From sip-bounces@ietf.org Sat Jan 12 08:48:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgiz-000140-Bq; Sat, 12 Jan 2008 08:48:37 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDgiy-00013v-5e for sip-confirm+ok@megatron.ietf.org; Sat, 12 Jan 2008 08:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgix-00013n-SE for sip@ietf.org; Sat, 12 Jan 2008 08:48:35 -0500 Received: from fk-out-0910.google.com ([209.85.128.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDgix-0000zM-9q for sip@ietf.org; Sat, 12 Jan 2008 08:48:35 -0500 Received: by fk-out-0910.google.com with SMTP id z23so1027067fkz.5 for ; Sat, 12 Jan 2008 05:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=DGh/I/pFAN4XgqFLbuE2krN1yOGZPuL59Lv7/ZlBfMU=; b=p8EmLUcyQExkfbxbMKgLsUJdSV8JRmuJFAR5bg9Wh/A7YC1JHsUqOTyYcofdvAo6RBnzxpcIMVM5cJJb/q6eKo31Xhv6n4SGUuafsR7PodvbcUyCj4P3qfOGe6Us/dC6R2lKVUhYwQjKgpTfxyGz80PL+w0yBQdboD7BZrENCKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RM1y5S/usYFjWvVNWmGSjmiEGR5O50R007yy5c+2LdZttC5HGLilTwFszglZPJBQD4Os579NywVzQs6+Bs6jzk9yXtSbmPHPLzrRpm+Rhnn7c/Hlln0oaMKHjDsB/njtYOO3KPGj+vzPR9mkxSBGjf7ap7n+r1xofYVLPJf9jhU= Received: by 10.78.132.2 with SMTP id f2mr5033206hud.44.1200145714274; Sat, 12 Jan 2008 05:48:34 -0800 (PST) Received: by 10.78.107.18 with HTTP; Sat, 12 Jan 2008 05:48:34 -0800 (PST) Message-ID: <7389c8a20801120548x6094bce6h19bc971eb436bd97@mail.gmail.com> Date: Sat, 12 Jan 2008 11:48:34 -0200 From: "Nadya Zanon" To: sip@ietf.org Subject: Re: [Sip] I'm a SIP beginner In-Reply-To: <398BC7886A1203478496A71B72877C23CD794492@exchange-01.WIN.NOMINUM.COM> MIME-Version: 1.0 References: <7389c8a20801021132k3462841ct3b27ef8636fb6cca@mail.gmail.com> <398BC7886A1203478496A71B72877C23CD794492@exchange-01.WIN.NOMINUM.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0989618396==" Errors-To: sip-bounces@ietf.org --===============0989618396== Content-Type: multipart/alternative; boundary="----=_Part_5113_24378174.1200145714269" ------=_Part_5113_24378174.1200145714269 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Aslam, I took a look at RFC3666 and I can see only flows for call establishment. I'd like to know if there is some other recommendation or draft about mapping of ISDN features in context ISDN PBX - SIP. Thanks for your attention. I really appreciated. On 1/2/08, Aslam Khan wrote: > > Hi, > > > > For SIP-PSTN interface you can look at: rfc3398/rfc3666. > > > > Thanks > ------------------------------ > > *From:* Nadya Zanon [mailto:nadya.zanon@gmail.com] > *Sent:* Wednesday, January 02, 2008 11:32 AM > *To:* sip@ietf.org > *Subject:* [Sip] I'm a SIP beginner > > > > Hello All, > > > > I'm a SIP beginner, probably my questions in the begin will be silly but I > believe that you will understand me. > > > > I have two questions for now: > > > > 1) Are there some place where I can find a bunch of drafts for mapping of > PSTN features on SIP? > > 2) Are ther some gateway and standard that maps SMS messages on SIP? I > mean, are there some mapping from GSM for example to SIP? > > > > > > Thanks in advance, > > > > Nadya Zanon > ------=_Part_5113_24378174.1200145714269 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello Aslam,
 
I took a look at RFC3666 and I can see only flows for call establishment.
I'd like to know if there is some other recommendation or draft about mapping of ISDN features in context ISDN PBX - SIP.
 
Thanks for your attention. I really appreciated.

 
On 1/2/08, Aslam Khan <Aslam.Khan@nominum.com> wrote:

Hi,

 

For SIP-PSTN interface you can look at: rfc3398/rfc3666.

 

Thanks

From: Nadya Zanon [mailto: nadya.zanon@gmail.com]
Sent: Wednesday, January 02, 2008 11:32 AM
To: sip@ietf.org
Subject: [Sip] I'm a SIP beginner

 

Hello All,

 

I'm a SIP beginner, probably my questions in the begin will be silly but I believe that you will understand me.

 

I have two questions for now:

 

1) Are there some place where I can find a bunch of drafts for mapping of PSTN features on SIP?

2) Are ther some gateway and standard that maps SMS messages on SIP? I mean, are there some mapping from GSM for example to SIP?

 

 

Thanks in advance,

 

Nadya Zanon


------=_Part_5113_24378174.1200145714269-- --===============0989618396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0989618396==-- From sip-bounces@ietf.org Sat Jan 12 22:12:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDtGk-00005t-C2; Sat, 12 Jan 2008 22:12:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JDtGj-00005o-5g for sip-confirm+ok@megatron.ietf.org; Sat, 12 Jan 2008 22:12:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDtGi-00005g-Oa for sip@ietf.org; Sat, 12 Jan 2008 22:12:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDtGi-00009H-4K for sip@ietf.org; Sat, 12 Jan 2008 22:12:16 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jan 2008 19:12:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0D3CF8O029610; Sat, 12 Jan 2008 19:12:15 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0D3CAiX016309; Sun, 13 Jan 2008 03:12:10 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Jan 2008 22:12:09 -0500 Received: from [10.86.240.235] ([10.86.240.235]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Jan 2008 22:12:09 -0500 Message-ID: <4789818A.6010302@cisco.com> Date: Sat, 12 Jan 2008 22:12:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases? References: <0D5F89FAC29E2C41B98A6A762007F5D05494DD@GBNTHT12009MSX.gb002.siemens.net> <1BC9F2EF-86C7-4D79-BDB1-F76A9E900D51@softarmor.com> In-Reply-To: <1BC9F2EF-86C7-4D79-BDB1-F76A9E900D51@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2008 03:12:09.0488 (UTC) FILETIME=[15880100:01C85592] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3765; t=1200193935; x=1201057935; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-kaplan-sip-info-use-cases -00=20-=20more=20use=20cases? |Sender:=20; bh=DNMRTvU6NaComwh7DNEjFnwD5cFBK0keWh1wXsyvYx4=; b=EWdVarIgtLCzK8KmJwCugrYLJQxlamMN40YqeT1jWLo/fPfmLD6u7A6pxF +39gTaDYzwRrF/KBAAST2JhxBuyZaysAw5alRzGBmegVMSTNwM0mM4CDfR9E fnhRQ1WfcE; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: IETF SIP List , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline... Dean Willis wrote: > > On Jan 9, 2008, at 3:58 AM, Elwell, John wrote: > >> 4. The use of offer-answer to achieve hold-retrieve fails to give an >> explicit indication of what is happening. An explicit indication of >> things like hold, retrieve, microphone mute, speaker mute, camera >> on/off, recorder on/off, etc. might be quite helpful. Of course, there >> will normally be an offer-answer exchange at the same time, so inclusion >> of the notification in a re-INVITE or UPDATE request might be more >> useful than using INFO. > > I suspect adding something to the reINVITE to convey explicit semantics > would be much better than an INFO here. The problem with giving an explicit indication of what is going on is that it requires agreement on the set of things that *can* go on. This means standardizing a set of features, which probably isn't going to happen, because it will have the effect of limiting feature development. >> 5. Concerning 6.7 (soft-key labels), a problem here is that the >> notifying UA might not have knowledge of soft key availability at the >> receiving UA. In certain closed environments (e.g., involving a UA and >> its local voicemail server) it may work, but I am not sure it would work >> well in general. Having said that, where it does work, perhaps other >> parameters at the device can be controlled in this way, e.g., microphone >> and speaker volume (especially if this control is based on say a web >> interface, so the user is really controlling his/her own settings from >> the web page rather than directly on the device). > > A soft-key INFO package would need to describe availability. This is a > fundamental problem from KPML, and to the extent it is solvable by KPML > in a SUBSCRIBE dialog, it should be solvable in an INVITE dialog. > >> >> 6. When a B2BUA performs 3PCC there is plenty of scope for the UAs to >> lose track of what is happening. For example, when a B2BUA holds, >> retrieves, transfers calls, joins calls, pre-empts calls, etc., there is >> currently no explicit information - only perhaps a re-INVITE request. >> Thus it can be difficult to know how to interpret things like identity. >> Say a UA receives a re-INVITE request with a new PAI, it might deduce >> that something like call transfer has occurred. However, if it receives >> a re-INVITE request without a PAI, does it mean the previous PAI is >> still valid, or does it mean, following transfer, there is no longer any >> identity available? Of course, INFO might not always be the most >> appropriate method to use for such notification if an offer-answer >> exchange is needed at the same time. > > I'm thinking this is totally NOT an INFO problem. If it needs to be > solved, it needs to happen in the 3PCC reINVITE sequence. Same comment as for (4). Paul >> 7. There might be some usages to do with interworking with TDM, e.g., >> advice of charge during a call, user-to-user information during a call. >> > > Clearly, all the old TDM interworking mid-call events work better with > the new INFO. Advice-of-charge would appear to be easily solved with > INFO, except that some use cases for it require delivering the final AOC > after the call has completed. There may some flexibility on this, of > course, but a dialog-correlated MESSAGE to the GRUU may be cleaner. > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 14 06:56:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENvQ-0003Av-DT; Mon, 14 Jan 2008 06:56:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JENvO-0002vP-O0 for sip-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 06:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JENvO-0002ud-DQ for sip@ietf.org; Mon, 14 Jan 2008 06:56:18 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JENvN-0001h0-RM for sip@ietf.org; Mon, 14 Jan 2008 06:56:18 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B954720977; Mon, 14 Jan 2008 12:56:16 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-9b-478b4de0bd9f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 977D820AE6; Mon, 14 Jan 2008 12:56:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 12:56:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Mon, 14 Jan 2008 12:56:15 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" X-OriginalArrivalTime: 14 Jan 2008 11:56:16.0378 (UTC) FILETIME=[77C05DA0:01C856A4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, "Elwell, John" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois,=20 >I think what you meant by Target was more the "Current"=20 >target as opposed to the Initiatl Target. Yes. =20 >And if that's the case, then I don't see why it is different=20 >from P-Called-ID (although I might be missing something with=20 >what the P-Called_ID is supposed to be). In the draft we try to explain the difference. But, we are working on the text to make it more clear. The P-CPI is inserted when the R-URI is rewritten by the Contact address of the UAS. RFC3455 calls that operation "retargeting", but we don't think that is the definition for retarget used in the ua-loose-route draft, which says: "When a home proxy receives a request and accesses a location service, the resulting contact(s) obtained from the location service are considered the last hop in the route towards the entity addressed by the Request-URI. Since that target, almost by definition, can claim the identity of the URI prior to translation, the operation is one of routing and not retargeting." So, if we follow the definitions in the ua-loose-route draft, P-CPI would be inserted due to a reroute - not retarget. But, no matter whether we call it retarget or reroute, the point is that the P-CPI is inserted when the R-URI is rewritten with the Contact address of the UAS. The scope of Target is wider than that, and can be used in any retargeting situation. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 14 07:15:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOE3-0004aI-3O; Mon, 14 Jan 2008 07:15:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEOE2-0004aD-43 for sip-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 07:15:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEOE1-0004a1-PH for sip@ietf.org; Mon, 14 Jan 2008 07:15:33 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEOE1-0007nd-BQ for sip@ietf.org; Mon, 14 Jan 2008 07:15:33 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0ECGHhi025269; Mon, 14 Jan 2008 06:16:24 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 14:15:15 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 14:15:15 +0200 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 14:15:15 +0200 Message-ID: <478B5239.7060803@nokia.com> Date: Mon, 14 Jan 2008 14:14:49 +0200 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: ext Avshalom Houri References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2008 12:15:15.0222 (UTC) FILETIME=[1E8E2B60:01C856A7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-xcapevent-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Avshalom, sorry for slow response... ext Avshalom Houri wrote: > > Wish to get a clarification regarding what will happen when we > subscribe to the > resources below and the first entry does not exist while the other two > do exist. > Assume that we get a pending notification, when and how will it be > possible to > know which resource does exist and which one does not. > > What will be the content of the pending notification and how it will > be possible > to know which one exist? > > > > > > > > > > > --Avshalom > The initial full notification will list all existing resources, so given the resource-lists document (index) doesn't exist it will not be indicated within the notification. So the element will be indicated and possibly zero or multiple documents within the pidf-manipulataion collection. So there are no reason indications like error codes within the notifications, the resources simply doesn't exist within the notification body. So a client knows what it tries to retrieve and the full notification will list what resources are available, i.e. some pretty simple logic on a client side. br, jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 14 11:58:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESdj-0000WB-Us; Mon, 14 Jan 2008 11:58:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JESdi-0000Vf-Lq for sip-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 11:58:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESdi-0000VX-An for sip@ietf.org; Mon, 14 Jan 2008 11:58:22 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JESdh-0006jd-Js for sip@ietf.org; Mon, 14 Jan 2008 11:58:21 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m0EGwFLn026855 for ; Mon, 14 Jan 2008 10:58:20 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 10:58:09 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 17:58:07 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jan 2008 17:58:06 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001B09071@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delivering request-URI and parameters to UAS via proxy Thread-index: AchWzqJNXVX4sjNuQSaW1d5oVZlILg== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 14 Jan 2008 16:58:07.0651 (UTC) FILETIME=[A2E94F30:01C856CE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] Delivering request-URI and parameters to UAS via proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) In fulfilment of our charter items of Dec 2007 Delivering request-URI and parameters to UAS via proxy to WGLC =20 Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) We now have a couple of proposals on the table for solving the problem. The original draft from Jonathan and which led to the creation of the charter items by the WG is unfortunately expired, but is at: http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt The alternative document from Christer, etc is at: http://www.ietf.org/internet-drafts/draft-holmberg-sip-target-uri-delive ry-00.txt We obviously need to make a decision between the two approaches so please attempt to address the following specific points via the mailing list: 1) Problem cases: These are summarised in section 4.4 of draft-rosenberg-sip-ua-loose-route-01 and from my read of the other draft, I don't believe that this draft adds any others. If you believe there are other cases that should be covered by the solution, then please identify them. If there is support on any new problem cases, I would encourage the authors of both drafts to add text concerning these problem cases. 2) Clarifications: If for any reason you don't understand either draft, or believe that there are technical issues that are not represented in the current draft, please post your questions / comments to the list. I would encourage authors of both drafts to revise as frequently as appropriate to reflect the current state of discussion. 3) Support for either position. If you wish to indicate support for either position please do so, but please accompany this is technical reasoning as to why you have this position, as that will help other members of the WG form a position. I would encourage as much list discussion as possible before Philadelphia. I suspect we will need to have a discussion at the face-to-face meeting in Philadephia, but list discussion is essential prior to that. If we can solve this positions on list, then well and good, and even better (that is how we are meant to make decisions). Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 14 20:08:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEaHx-00062r-D3; Mon, 14 Jan 2008 20:08:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEaHw-00062l-FS for sip-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 20:08:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEaHw-00062d-5l for sip@ietf.org; Mon, 14 Jan 2008 20:08:24 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEaHv-0001JR-Qh for sip@ietf.org; Mon, 14 Jan 2008 20:08:24 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0F18KJ19511; Tue, 15 Jan 2008 01:08:20 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Mon, 14 Jan 2008 19:08:19 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMA== References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, "Elwell, John" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hum. I guess then P-Called-ID would then be useful with Loose-route as well (although now I'm thinking that History-Info covers it). I think explaining all that in great and precise details, with a = concrete=20 example would be very useful. And then we could compare P-Target with Loose-route.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, January 14, 2008 03:56 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy >=20 >=20 > Hi Francois,=20 >=20 > >I think what you meant by Target was more the "Current"=20 > >target as opposed to the Initiatl Target. >=20 > Yes. > =20 > >And if that's the case, then I don't see why it is different from=20 > >P-Called-ID (although I might be missing something with what the=20 > >P-Called_ID is supposed to be). >=20 > In the draft we try to explain the difference. But, we are=20 > working on the text to make it more clear. >=20 > The P-CPI is inserted when the R-URI is rewritten by the=20 > Contact address of the UAS. RFC3455 calls that operation=20 > "retargeting", but we don't think that is the definition for=20 > retarget used in the ua-loose-route draft, which says: >=20 > "When a home proxy receives a request and accesses a location=20 > service, the resulting contact(s) obtained from the location=20 > service are considered the last hop in the route towards the=20 > entity addressed by the Request-URI. Since that target,=20 > almost by definition, can claim the identity of the URI prior=20 > to translation, the operation is one of routing and not retargeting." >=20 > So, if we follow the definitions in the ua-loose-route draft,=20 > P-CPI would be inserted due to a reroute - not retarget. >=20 > But, no matter whether we call it retarget or reroute, the=20 > point is that the P-CPI is inserted when the R-URI is=20 > rewritten with the Contact address of the UAS. The scope of=20 > Target is wider than that, and can be used in any retargeting=20 > situation. >=20 > Regards, >=20 > Christer >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 03:48:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEhT7-0006rg-Dh; Tue, 15 Jan 2008 03:48:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEhT5-0006rb-F1 for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 03:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEhSy-0006pr-OP for sip@ietf.org; Tue, 15 Jan 2008 03:48:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEhSw-00084K-VF for sip@ietf.org; Tue, 15 Jan 2008 03:48:16 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C68EA213F8; Tue, 15 Jan 2008 09:48:11 +0100 (CET) X-AuditID: c1b4fb3e-ae69ebb00000459d-5f-478c734b8377 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 988C1211F4; Tue, 15 Jan 2008 09:48:11 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:48:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Tue, 15 Jan 2008 09:48:10 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DA References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" X-OriginalArrivalTime: 15 Jan 2008 08:48:11.0344 (UTC) FILETIME=[5BC29500:01C85753] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org, "Elwell, John" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 P-CPI could probably be useful in some cases, in addition to Loose Route/Target. And, as the draft says, P-CPI will still have to be used in IMS, because there are procedures defined for it. However, again, the purpose of the draft was to provide an alternative to the Loose Route alternative, and that alternative is Target only.=20 I am working on an updated version of the draft to make that more clear. Regards, Christer >Hum. I guess then P-Called-ID would then be useful with=20 >Loose-route as well (although now I'm thinking that=20 >History-Info covers it). >=20 >I think explaining all that in great and precise details,=20 >with a concrete example would be very useful. >=20 >And then we could compare P-Target with Loose-route.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, January 14, 2008 03:56 > > To: Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > > Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS=20 > > via proxy > >=20 > >=20 > > Hi Francois, > >=20 > > >I think what you meant by Target was more the "Current"=20 > > >target as opposed to the Initiatl Target. > >=20 > > Yes. > > =20 > > >And if that's the case, then I don't see why it is different from=20 > > >P-Called-ID (although I might be missing something with what the=20 > > >P-Called_ID is supposed to be). > >=20 > > In the draft we try to explain the difference. But, we are=20 > working on=20 > > the text to make it more clear. > >=20 > > The P-CPI is inserted when the R-URI is rewritten by the Contact=20 > > address of the UAS. RFC3455 calls that operation=20 > "retargeting", but we=20 > > don't think that is the definition for retarget used in the=20 > > ua-loose-route draft, which says: > >=20 > > "When a home proxy receives a request and accesses a=20 > location service,=20 > > the resulting contact(s) obtained from the location service are=20 > > considered the last hop in the route towards the entity=20 > addressed by=20 > > the Request-URI. Since that target, almost by definition,=20 > can claim=20 > > the identity of the URI prior to translation, the operation=20 > is one of=20 > > routing and not retargeting." > >=20 > > So, if we follow the definitions in the ua-loose-route draft, P-CPI=20 > > would be inserted due to a reroute - not retarget. > >=20 > > But, no matter whether we call it retarget or reroute, the point is=20 > > that the P-CPI is inserted when the R-URI is rewritten with the=20 > > Contact address of the UAS. The scope of Target is wider than that,=20 > > and can be used in any retargeting situation. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 04:20:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEhxo-0006U2-Dz; Tue, 15 Jan 2008 04:20:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEhxn-0006Tw-39 for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 04:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEhxm-0006To-Pl for sip@ietf.org; Tue, 15 Jan 2008 04:20:06 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEhxk-0000Lp-Tx for sip@ietf.org; Tue, 15 Jan 2008 04:20:06 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUO0068VHXEGK@siemenscomms.co.uk> for sip@ietf.org; Tue, 15 Jan 2008 09:20:02 +0000 (GMT) Date: Tue, 15 Jan 2008 09:20:01 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy In-reply-to: A To: Christer Holmberg , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy thread-index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DAAAacccA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, I guess what still confuses me is, when both Target and P-CPI are used, which comes first, i.e., which represents the earlier target? When I read the draft, I thought Target was earlier. From various clarifying emails I now get the impression that Target is later. Can you confirm? Picking up on Francois' point about History-Info, with the introduction of Target and P-CPI we do indeed have a lot of URIs, and of course History-Info can already convey all these URIs and any others. The difference is that History-Info does not give particular semantics to each of the URIs it conveys - they are simply a succession of targets. With Target and P-CPI we are aiming to define specific semantics. I am concerned whether we will be able to define these semantics tightly enough to ensure consistent implementations. The more URIs we try to define, the harder it will be to assign each one a clearly distinguishable meaning. I hope the next draft will help. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 15 January 2008 08:48 > To: Francois Audet > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy >=20 >=20 > Hi,=20 >=20 > P-CPI could probably be useful in some cases, in addition to Loose > Route/Target. And, as the draft says, P-CPI will still have to be used > in IMS, because there are procedures defined for it. >=20 > However, again, the purpose of the draft was to provide an alternative > to the Loose Route alternative, and that alternative is Target only.=20 >=20 > I am working on an updated version of the draft to make that=20 > more clear. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > >Hum. I guess then P-Called-ID would then be useful with=20 > >Loose-route as well (although now I'm thinking that=20 > >History-Info covers it). > >=20 > >I think explaining all that in great and precise details,=20 > >with a concrete example would be very useful. > >=20 > >And then we could compare P-Target with Loose-route.=20 >=20 >=20 >=20 >=20 >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Monday, January 14, 2008 03:56 > > > To: Audet, Francois (SC100:3055) > > > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > > > Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > > > via proxy > > >=20 > > >=20 > > > Hi Francois, > > >=20 > > > >I think what you meant by Target was more the "Current"=20 > > > >target as opposed to the Initiatl Target. > > >=20 > > > Yes. > > > =20 > > > >And if that's the case, then I don't see why it is=20 > different from=20 > > > >P-Called-ID (although I might be missing something with what the=20 > > > >P-Called_ID is supposed to be). > > >=20 > > > In the draft we try to explain the difference. But, we are=20 > > working on=20 > > > the text to make it more clear. > > >=20 > > > The P-CPI is inserted when the R-URI is rewritten by the Contact=20 > > > address of the UAS. RFC3455 calls that operation=20 > > "retargeting", but we=20 > > > don't think that is the definition for retarget used in the=20 > > > ua-loose-route draft, which says: > > >=20 > > > "When a home proxy receives a request and accesses a=20 > > location service,=20 > > > the resulting contact(s) obtained from the location service are=20 > > > considered the last hop in the route towards the entity=20 > > addressed by=20 > > > the Request-URI. Since that target, almost by definition,=20 > > can claim=20 > > > the identity of the URI prior to translation, the operation=20 > > is one of=20 > > > routing and not retargeting." > > >=20 > > > So, if we follow the definitions in the ua-loose-route=20 > draft, P-CPI=20 > > > would be inserted due to a reroute - not retarget. > > >=20 > > > But, no matter whether we call it retarget or reroute,=20 > the point is=20 > > > that the P-CPI is inserted when the R-URI is rewritten with the=20 > > > Contact address of the UAS. The scope of Target is wider=20 > than that,=20 > > > and can be used in any retargeting situation. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 05:41:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEjEQ-0002Gz-3x; Tue, 15 Jan 2008 05:41:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEjEN-0002AL-Pe for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 05:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEjEN-0002AD-Fx for sip@ietf.org; Tue, 15 Jan 2008 05:41:19 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEjEM-0001vt-He for sip@ietf.org; Tue, 15 Jan 2008 05:41:19 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1BA812116C; Tue, 15 Jan 2008 11:41:17 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-dc-478c8dcc30e0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DBE912114B; Tue, 15 Jan 2008 11:41:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 11:41:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Tue, 15 Jan 2008 11:41:15 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DAAAacccAAAIe2AA== References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Francois Audet" X-OriginalArrivalTime: 15 Jan 2008 10:41:16.0754 (UTC) FILETIME=[282DFB20:01C85763] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John, >I guess what still confuses me is, when both Target and P-CPI=20 >are used, which comes first, i.e., which represents the=20 >earlier target? When I read the draft, I thought Target was=20 >earlier. From various clarifying emails I now get the=20 >impression that Target is later. Can you confirm? I am not sure what you mean by "earlier" target.=20 Target, if present, always represents the current target. A receiving entity that receives a request without a Target header has to assume that the Request-URI represents the current target. When no Target header is available on the request then the Target is inserted when a reroute is performed. P-CPI is ONLY used to maintain the R-URI which is rewritten by the contact of the UAS. I.e. by the home proxy which is usually at the end of a chain of proxies. When both Target and P-CPI are used: Target always represents the current target. P-CPI always represents the AOR received by the home proxy which may in some cases be the same as the current target but it may also be the last route (not equal to the current target) taken to deliver the request.=20 >Picking up on Francois' point about History-Info, with the=20 >introduction of Target and P-CPI we do indeed have a lot of=20 >URIs, and of course History-Info can already convey all these=20 >URIs and any others. The difference is that History-Info does=20 >not give particular semantics to each of the URIs it conveys=20 >- they are simply a succession of targets. Yes, we agree with your analysis regarding History-Info. The UA-loose-draft discusses further issues with using History-Info. >With Target and P-CPI we are aiming to define specific=20 >semantics. I am concerned whether we will be able to define=20 >these semantics tightly enough to ensure consistent=20 >implementations. Target always represents the current target. See above. P-CPI does not represent the current target in all cases. See above. >The more URIs we try to define, the harder it will be to assign each one a clearly distinguishable meaning. I hope the next draft will help. In the next version of the draft I will remove as much as possible about P-CPI, in order not to cause confusion. I will only keep some text where I describe the semantical difference between Target and P-CPI. I also do agree with one of your previous comments, that we should clarify the meaning of all the URIs we're using - and that should be done no matter if we adopt Target or not. Regards. Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 15 January 2008 08:48 > > To: Francois Audet > > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > > Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS=20 > > via proxy > >=20 > >=20 > > Hi, > >=20 > > P-CPI could probably be useful in some cases, in addition to Loose=20 > > Route/Target. And, as the draft says, P-CPI will still have=20 > to be used=20 > > in IMS, because there are procedures defined for it. > >=20 > > However, again, the purpose of the draft was to provide an=20 > alternative=20 > > to the Loose Route alternative, and that alternative is Target only. > >=20 > > I am working on an updated version of the draft to make that more=20 > > clear. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > >Hum. I guess then P-Called-ID would then be useful with=20 > Loose-route=20 > > >as well (although now I'm thinking that History-Info covers it). > > >=20 > > >I think explaining all that in great and precise details, with a=20 > > >concrete example would be very useful. > > >=20 > > >And then we could compare P-Target with Loose-route.=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Monday, January 14, 2008 03:56 > > > > To: Audet, Francois (SC100:3055) > > > > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat;=20 > Elwell, John > > > > Subject: RE: [Sip] RE: Delivering request-URI and > > parameters to UAS > > > > via proxy > > > >=20 > > > >=20 > > > > Hi Francois, > > > >=20 > > > > >I think what you meant by Target was more the "Current"=20 > > > > >target as opposed to the Initiatl Target. > > > >=20 > > > > Yes. > > > > =20 > > > > >And if that's the case, then I don't see why it is > > different from > > > > >P-Called-ID (although I might be missing something=20 > with what the=20 > > > > >P-Called_ID is supposed to be). > > > >=20 > > > > In the draft we try to explain the difference. But, we are > > > working on > > > > the text to make it more clear. > > > >=20 > > > > The P-CPI is inserted when the R-URI is rewritten by=20 > the Contact=20 > > > > address of the UAS. RFC3455 calls that operation > > > "retargeting", but we > > > > don't think that is the definition for retarget used in the=20 > > > > ua-loose-route draft, which says: > > > >=20 > > > > "When a home proxy receives a request and accesses a > > > location service, > > > > the resulting contact(s) obtained from the location service are=20 > > > > considered the last hop in the route towards the entity > > > addressed by > > > > the Request-URI. Since that target, almost by definition, > > > can claim > > > > the identity of the URI prior to translation, the operation > > > is one of > > > > routing and not retargeting." > > > >=20 > > > > So, if we follow the definitions in the ua-loose-route > > draft, P-CPI > > > > would be inserted due to a reroute - not retarget. > > > >=20 > > > > But, no matter whether we call it retarget or reroute, > > the point is > > > > that the P-CPI is inserted when the R-URI is rewritten with the=20 > > > > Contact address of the UAS. The scope of Target is wider > > than that, > > > > and can be used in any retargeting situation. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 06:50:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEkJa-0003P0-FV; Tue, 15 Jan 2008 06:50:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEkJZ-0003Ov-LG for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 06:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEkJZ-0003On-AK for sip@ietf.org; Tue, 15 Jan 2008 06:50:45 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEkJY-0000Hy-Re for sip@ietf.org; Tue, 15 Jan 2008 06:50:45 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUO00F5BOWHX6@siemenscomms.co.uk> for sip@ietf.org; Tue, 15 Jan 2008 11:50:41 +0000 (GMT) Date: Tue, 15 Jan 2008 11:50:41 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy In-reply-to: A To: Christer Holmberg , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593A46@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy thread-index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DAAAacccAAAIe2AAAE3pIA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> A X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer,=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 15 January 2008 10:41 > To: Elwell, John; Francois Audet > Cc: sip@ietf.org; Paul Kyzivat; DRAGE, Keith (Keith) > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy >=20 >=20 > Hi John, >=20 > >I guess what still confuses me is, when both Target and P-CPI=20 > >are used, which comes first, i.e., which represents the=20 > >earlier target? When I read the draft, I thought Target was=20 > >earlier. From various clarifying emails I now get the=20 > >impression that Target is later. Can you confirm? >=20 > I am not sure what you mean by "earlier" target.=20 [JRE]Assuming that the target changes as the request progresses downstream, I meant the one that occurs first. >=20 > Target, if present, always represents the current target. A receiving > entity that receives a request without a Target header has to assume > that the Request-URI represents the current target. When no Target > header is available on the request then the Target is inserted when a > reroute is performed. >=20 > P-CPI is ONLY used to maintain the R-URI which is rewritten by the > contact of the UAS. I.e. by the home proxy which is usually at the end > of a chain of proxies. >=20 > When both Target and P-CPI are used: Target always represents the > current target. P-CPI always represents the AOR received by the home > proxy which may in some cases be the same as the current target but it > may also be the last route (not equal to the current target) taken to > deliver the request.=20 [JRE] I think I am getting there. So the target could be some sort of call centre group, for example, and P-CPI could be the AoR of the selected member of that group. Correct? I am a little concerned about using the term "AoR" in the definition of these AoRs. What about a request targeted at a GRUU? I would imagine the Target and P-CPI would both contain the GRUU, which is not an AoR. John =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 07:49:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElEI-0001Js-LI; Tue, 15 Jan 2008 07:49:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JElEH-0001I3-Ks for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 07:49:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElEH-0001Hv-9s for sip@ietf.org; Tue, 15 Jan 2008 07:49:21 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JElEG-0001HQ-MW for sip@ietf.org; Tue, 15 Jan 2008 07:49:21 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D66842079D; Tue, 15 Jan 2008 13:49:19 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-27-478cabcf3fea Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6A0F201C3; Tue, 15 Jan 2008 13:49:19 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 13:49:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Tue, 15 Jan 2008 13:49:18 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593A46@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DAAAacccAAAIe2AAAE3pIAAADKqtA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593A46@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Francois Audet" X-OriginalArrivalTime: 15 Jan 2008 12:49:19.0513 (UTC) FILETIME=[0B75F890:01C85775] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John,=20 >>Target, if present, always represents the current target. A receiving=20 >>entity that receives a request without a Target header has to assume=20 >>that the Request-URI represents the current target. When no Target=20 >>header is available on the request then the Target is inserted when a=20 >>reroute is performed. >>=20 >>P-CPI is ONLY used to maintain the R-URI which is rewritten by the=20 >>contact of the UAS. I.e. by the home proxy which is usually=20 >>at the end of a chain of proxies. >>=20 >>When both Target and P-CPI are used: Target always represents the=20 >>current target. P-CPI always represents the AOR received by the home=20 >>proxy which may in some cases be the same as the current target but it >>may also be the last route (not equal to the current target) taken to=20 >>deliver the request. >> >[JRE] I think I am getting there. So the target could be some=20 >sort of call centre group, for example, and P-CPI could be=20 >the AoR of the selected member of that group. Correct? Correct. >I am a little concerned about using the term "AoR" in the=20 >definition of these AoRs. What about a request targeted at a=20 >GRUU? I would imagine the Target and P-CPI would both contain=20 >the GRUU, which is not an AoR. Good point. I guess we could simply say URI. We'll fix that in the next version of the document. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 08:01:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElPn-0008QR-R4; Tue, 15 Jan 2008 08:01:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JElPl-0008KZ-Iy for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 08:01:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElPk-0008HG-Ud for sip@ietf.org; Tue, 15 Jan 2008 08:01:12 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JElPk-00040w-78 for sip@ietf.org; Tue, 15 Jan 2008 08:01:12 -0500 X-IronPort-AV: E=Sophos;i="4.24,287,1196658000"; d="scan'208";a="83377783" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2008 08:01:04 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0FD138Q013570; Tue, 15 Jan 2008 08:01:03 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0FD13ua013244; Tue, 15 Jan 2008 13:01:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 08:00:26 -0500 Received: from [10.86.243.168] ([10.86.243.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 08:00:26 -0500 Message-ID: <478CAE6C.3040703@cisco.com> Date: Tue, 15 Jan 2008 08:00:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2008 13:00:26.0466 (UTC) FILETIME=[98FEEC20:01C85776] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6479; t=1200402063; x=1201266063; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Delivering=20request-UR I=20and=20parameters=20to=20UAS=20via=20proxy |Sender:=20 |To:=20Christer=20Holmberg=20; bh=YUXo9dgj5cOX3EbdAT1QMCruh6JrjOfIc/9K+hOnKPc=; b=qJgoNUkkMvw3wxvy14/eVI6uSCELVMrgIJDdvnK29I94NaVYt8c6/kNy47 zSJop/wEhfVMdDTR/sHnayLEzx/fxmg3jruW+3+RObDxBkXNp7xjVK40VzYU gyEvoz8RVy; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Francois Audet , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am still confused by the distinction between Target and P-CPI. I agree that you have described rules for updating Target that are different from those for updating P-CPI. But it seems to me that is a distinction without a significant difference. For the recipient of the request, the two are used the same way, toward the same end. If anything I would view the rules for Target to be just a bug fix on P-CPI. Paul Christer Holmberg wrote: > Hi John, > >> I guess what still confuses me is, when both Target and P-CPI >> are used, which comes first, i.e., which represents the >> earlier target? When I read the draft, I thought Target was >> earlier. From various clarifying emails I now get the >> impression that Target is later. Can you confirm? > > I am not sure what you mean by "earlier" target. > > Target, if present, always represents the current target. A receiving > entity that receives a request without a Target header has to assume > that the Request-URI represents the current target. When no Target > header is available on the request then the Target is inserted when a > reroute is performed. > > P-CPI is ONLY used to maintain the R-URI which is rewritten by the > contact of the UAS. I.e. by the home proxy which is usually at the end > of a chain of proxies. > > When both Target and P-CPI are used: Target always represents the > current target. P-CPI always represents the AOR received by the home > proxy which may in some cases be the same as the current target but it > may also be the last route (not equal to the current target) taken to > deliver the request. > >> Picking up on Francois' point about History-Info, with the >> introduction of Target and P-CPI we do indeed have a lot of >> URIs, and of course History-Info can already convey all these >> URIs and any others. The difference is that History-Info does >> not give particular semantics to each of the URIs it conveys >> - they are simply a succession of targets. > > Yes, we agree with your analysis regarding History-Info. The > UA-loose-draft discusses further issues with using History-Info. > >> With Target and P-CPI we are aiming to define specific >> semantics. I am concerned whether we will be able to define >> these semantics tightly enough to ensure consistent >> implementations. > > Target always represents the current target. See above. > > P-CPI does not represent the current target in all cases. See above. > >> The more URIs we try to define, the harder it will be to assign each > one a clearly distinguishable meaning. I hope the next draft will help. > > In the next version of the draft I will remove as much as possible about > P-CPI, in order not to cause confusion. I will only keep some text where > I describe the semantical difference between Target and P-CPI. > > I also do agree with one of your previous comments, that we should > clarify the meaning of all the URIs we're using - and that should be > done no matter if we adopt Target or not. > > Regards. > > Christer > > > > > > > > > > > > > > >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 15 January 2008 08:48 >>> To: Francois Audet >>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John >>> Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS >>> via proxy >>> >>> >>> Hi, >>> >>> P-CPI could probably be useful in some cases, in addition to Loose >>> Route/Target. And, as the draft says, P-CPI will still have >> to be used >>> in IMS, because there are procedures defined for it. >>> >>> However, again, the purpose of the draft was to provide an >> alternative >>> to the Loose Route alternative, and that alternative is Target only. >>> >>> I am working on an updated version of the draft to make that more >>> clear. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> Hum. I guess then P-Called-ID would then be useful with >> Loose-route >>>> as well (although now I'm thinking that History-Info covers it). >>>> >>>> I think explaining all that in great and precise details, with a >>>> concrete example would be very useful. >>>> >>>> And then we could compare P-Target with Loose-route. >>> >>> >>> >>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Monday, January 14, 2008 03:56 >>>>> To: Audet, Francois (SC100:3055) >>>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; >> Elwell, John >>>>> Subject: RE: [Sip] RE: Delivering request-URI and >>> parameters to UAS >>>>> via proxy >>>>> >>>>> >>>>> Hi Francois, >>>>> >>>>>> I think what you meant by Target was more the "Current" >>>>>> target as opposed to the Initiatl Target. >>>>> Yes. >>>>> >>>>>> And if that's the case, then I don't see why it is >>> different from >>>>>> P-Called-ID (although I might be missing something >> with what the >>>>>> P-Called_ID is supposed to be). >>>>> In the draft we try to explain the difference. But, we are >>>> working on >>>>> the text to make it more clear. >>>>> >>>>> The P-CPI is inserted when the R-URI is rewritten by >> the Contact >>>>> address of the UAS. RFC3455 calls that operation >>>> "retargeting", but we >>>>> don't think that is the definition for retarget used in the >>>>> ua-loose-route draft, which says: >>>>> >>>>> "When a home proxy receives a request and accesses a >>>> location service, >>>>> the resulting contact(s) obtained from the location service are >>>>> considered the last hop in the route towards the entity >>>> addressed by >>>>> the Request-URI. Since that target, almost by definition, >>>> can claim >>>>> the identity of the URI prior to translation, the operation >>>> is one of >>>>> routing and not retargeting." >>>>> >>>>> So, if we follow the definitions in the ua-loose-route >>> draft, P-CPI >>>>> would be inserted due to a reroute - not retarget. >>>>> >>>>> But, no matter whether we call it retarget or reroute, >>> the point is >>>>> that the P-CPI is inserted when the R-URI is rewritten with the >>>>> Contact address of the UAS. The scope of Target is wider >>> than that, >>>>> and can be used in any retargeting situation. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 12:04:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpD3-0006xc-WE; Tue, 15 Jan 2008 12:04:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEpD2-0006uM-Dj for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpD2-0006uE-3H for sip@ietf.org; Tue, 15 Jan 2008 12:04:20 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEpD1-00012T-Gr for sip@ietf.org; Tue, 15 Jan 2008 12:04:20 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0FH4GX16732; Tue, 15 Jan 2008 17:04:16 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Tue, 15 Jan 2008 11:04:09 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchUZtW5bDMRNv3qRbeBDq53RksY6wAC6fXwAAREC3AAAN5tsAAAvlqgAIQb/vAAHhqlMAAKS5DAAAacccAAEIci8A== References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Christer Holmberg" X-Spam-Score: -4.0 (----) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we should charge customers per URI in the protocol. We'd be rich.=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Tuesday, January 15, 2008 01:20 > To: Christer Holmberg; Audet, Francois (SC100:3055) > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy >=20 > Christer, >=20 > I guess what still confuses me is, when both Target and P-CPI=20 > are used, which comes first, i.e., which represents the=20 > earlier target? When I read the draft, I thought Target was=20 > earlier. From various clarifying emails I now get the=20 > impression that Target is later. Can you confirm? >=20 > Picking up on Francois' point about History-Info, with the=20 > introduction of Target and P-CPI we do indeed have a lot of=20 > URIs, and of course History-Info can already convey all these=20 > URIs and any others. The difference is that History-Info does=20 > not give particular semantics to each of the URIs it conveys=20 > - they are simply a succession of targets. > With Target and P-CPI we are aiming to define specific=20 > semantics. I am concerned whether we will be able to define=20 > these semantics tightly enough to ensure consistent=20 > implementations. The more URIs we try to define, the harder=20 > it will be to assign each one a clearly distinguishable=20 > meaning. I hope the next draft will help. >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 15 January 2008 08:48 > > To: Francois Audet > > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > > Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS=20 > > via proxy > >=20 > >=20 > > Hi, > >=20 > > P-CPI could probably be useful in some cases, in addition to Loose=20 > > Route/Target. And, as the draft says, P-CPI will still have=20 > to be used=20 > > in IMS, because there are procedures defined for it. > >=20 > > However, again, the purpose of the draft was to provide an=20 > alternative=20 > > to the Loose Route alternative, and that alternative is Target only. > >=20 > > I am working on an updated version of the draft to make that more=20 > > clear. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > >Hum. I guess then P-Called-ID would then be useful with=20 > Loose-route=20 > > >as well (although now I'm thinking that History-Info covers it). > > >=20 > > >I think explaining all that in great and precise details, with a=20 > > >concrete example would be very useful. > > >=20 > > >And then we could compare P-Target with Loose-route.=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Monday, January 14, 2008 03:56 > > > > To: Audet, Francois (SC100:3055) > > > > Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat;=20 > Elwell, John > > > > Subject: RE: [Sip] RE: Delivering request-URI and > > parameters to UAS > > > > via proxy > > > >=20 > > > >=20 > > > > Hi Francois, > > > >=20 > > > > >I think what you meant by Target was more the "Current"=20 > > > > >target as opposed to the Initiatl Target. > > > >=20 > > > > Yes. > > > > =20 > > > > >And if that's the case, then I don't see why it is > > different from > > > > >P-Called-ID (although I might be missing something=20 > with what the=20 > > > > >P-Called_ID is supposed to be). > > > >=20 > > > > In the draft we try to explain the difference. But, we are > > > working on > > > > the text to make it more clear. > > > >=20 > > > > The P-CPI is inserted when the R-URI is rewritten by=20 > the Contact=20 > > > > address of the UAS. RFC3455 calls that operation > > > "retargeting", but we > > > > don't think that is the definition for retarget used in the=20 > > > > ua-loose-route draft, which says: > > > >=20 > > > > "When a home proxy receives a request and accesses a > > > location service, > > > > the resulting contact(s) obtained from the location service are=20 > > > > considered the last hop in the route towards the entity > > > addressed by > > > > the Request-URI. Since that target, almost by definition, > > > can claim > > > > the identity of the URI prior to translation, the operation > > > is one of > > > > routing and not retargeting." > > > >=20 > > > > So, if we follow the definitions in the ua-loose-route > > draft, P-CPI > > > > would be inserted due to a reroute - not retarget. > > > >=20 > > > > But, no matter whether we call it retarget or reroute, > > the point is > > > > that the P-CPI is inserted when the R-URI is rewritten with the=20 > > > > Contact address of the UAS. The scope of Target is wider > > than that, > > > > and can be used in any retargeting situation. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 15 12:39:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpkx-0000oP-0z; Tue, 15 Jan 2008 12:39:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEpkw-0000oK-0s for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:39:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpkv-0000oC-LS for sip@ietf.org; Tue, 15 Jan 2008 12:39:21 -0500 Received: from smtp6.versatel.nl ([62.58.50.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEpku-0001FQ-LA for sip@ietf.org; Tue, 15 Jan 2008 12:39:21 -0500 Received: (qmail 9976 invoked by uid 0); 15 Jan 2008 17:40:14 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jan 2008 17:40:14 -0000 Message-ID: <478CEFB4.6070002@zonnet.nl> Date: Tue, 15 Jan 2008 18:39:00 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Paul Kyzivat , "Elwell, John" , Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we'll also need a new response code: 4xx I'm confused, too many URIs in request Seriously, a solution based on yet another header with an URI IMHO introduces more complexity/confusion than solving the issue is worth. Better to limit the scope of the problem we're trying to solve and document the known limitations / use cases. If the problem is to deliver the request URI to a UAS which is registered with its home proxy, and there is a mechanism by which the proxy can detect support by the UAS, Jonathan's solution is fine. To other proxies being in the path not supporting this mechanism it would still appear as basic loose routing, so I don't see the issue there (if needed we could extend the Path mechanism with some flag as done for outbound) Regards, Jeroen Francois Audet wrote: > I think we should charge customers per URI in the protocol. > > We'd be rich. > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Tuesday, January 15, 2008 01:20 >> To: Christer Holmberg; Audet, Francois (SC100:3055) >> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat >> Subject: RE: [Sip] RE: Delivering request-URI and parameters >> to UAS via proxy >> >> Christer, >> >> I guess what still confuses me is, when both Target and P-CPI >> are used, which comes first, i.e., which represents the >> earlier target? When I read the draft, I thought Target was >> earlier. From various clarifying emails I now get the >> impression that Target is later. Can you confirm? >> >> Picking up on Francois' point about History-Info, with the >> introduction of Target and P-CPI we do indeed have a lot of >> URIs, and of course History-Info can already convey all these >> URIs and any others. The difference is that History-Info does >> not give particular semantics to each of the URIs it conveys >> - they are simply a succession of targets. >> With Target and P-CPI we are aiming to define specific >> semantics. I am concerned whether we will be able to define >> these semantics tightly enough to ensure consistent >> implementations. The more URIs we try to define, the harder >> it will be to assign each one a clearly distinguishable >> meaning. I hope the next draft will help. >> >> John >> >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 15 January 2008 08:48 >>> To: Francois Audet >>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John >>> Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS >>> via proxy >>> >>> >>> Hi, >>> >>> P-CPI could probably be useful in some cases, in addition to Loose >>> Route/Target. And, as the draft says, P-CPI will still have >>> >> to be used >> >>> in IMS, because there are procedures defined for it. >>> >>> However, again, the purpose of the draft was to provide an >>> >> alternative >> >>> to the Loose Route alternative, and that alternative is Target only. >>> >>> I am working on an updated version of the draft to make that more >>> clear. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>>> Hum. I guess then P-Called-ID would then be useful with >>>> >> Loose-route >> >>>> as well (although now I'm thinking that History-Info covers it). >>>> >>>> I think explaining all that in great and precise details, with a >>>> concrete example would be very useful. >>>> >>>> And then we could compare P-Target with Loose-route. >>>> >>> >>> >>> >>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Monday, January 14, 2008 03:56 >>>>> To: Audet, Francois (SC100:3055) >>>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; >>>>> >> Elwell, John >> >>>>> Subject: RE: [Sip] RE: Delivering request-URI and >>>>> >>> parameters to UAS >>> >>>>> via proxy >>>>> >>>>> >>>>> Hi Francois, >>>>> >>>>> >>>>>> I think what you meant by Target was more the "Current" >>>>>> target as opposed to the Initiatl Target. >>>>>> >>>>> Yes. >>>>> >>>>> >>>>>> And if that's the case, then I don't see why it is >>>>>> >>> different from >>> >>>>>> P-Called-ID (although I might be missing something >>>>>> >> with what the >> >>>>>> P-Called_ID is supposed to be). >>>>>> >>>>> In the draft we try to explain the difference. But, we are >>>>> >>>> working on >>>> >>>>> the text to make it more clear. >>>>> >>>>> The P-CPI is inserted when the R-URI is rewritten by >>>>> >> the Contact >> >>>>> address of the UAS. RFC3455 calls that operation >>>>> >>>> "retargeting", but we >>>> >>>>> don't think that is the definition for retarget used in the >>>>> ua-loose-route draft, which says: >>>>> >>>>> "When a home proxy receives a request and accesses a >>>>> >>>> location service, >>>> >>>>> the resulting contact(s) obtained from the location service are >>>>> considered the last hop in the route towards the entity >>>>> >>>> addressed by >>>> >>>>> the Request-URI. Since that target, almost by definition, >>>>> >>>> can claim >>>> >>>>> the identity of the URI prior to translation, the operation >>>>> >>>> is one of >>>> >>>>> routing and not retargeting." >>>>> >>>>> So, if we follow the definitions in the ua-loose-route >>>>> >>> draft, P-CPI >>> >>>>> would be inserted due to a reroute - not retarget. >>>>> >>>>> But, no matter whether we call it retarget or reroute, >>>>> >>> the point is >>> >>>>> that the P-CPI is inserted when the R-URI is rewritten with the >>>>> Contact address of the UAS. The scope of Target is wider >>>>> >>> than that, >>> >>>>> and can be used in any retargeting situation. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 03:09:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Kr-00082C-Tt; Wed, 16 Jan 2008 03:09:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF3Kp-00081v-Dx for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:09:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Kh-00081Z-Dr for sip@ietf.org; Wed, 16 Jan 2008 03:09:11 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF3Kg-000224-7N for sip@ietf.org; Wed, 16 Jan 2008 03:09:11 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7DA0620F8B; Wed, 16 Jan 2008 09:09:09 +0100 (CET) X-AuditID: c1b4fb3c-af796bb0000030cf-70-478dbba5e88f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 484BD20703; Wed, 16 Jan 2008 09:09:09 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 09:09:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Wed, 16 Jan 2008 09:09:07 +0100 Message-ID: In-Reply-To: <478CAE6C.3040703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchXdrbiMugeMAL2SlmteE+kJF0BxQAoEZaQ References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <478CAE6C.3040703@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Jan 2008 08:09:08.0564 (UTC) FILETIME=[11C47940:01C85817] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Francois Audet , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I am still confused by the distinction between Target and P-CPI. >=20 >I agree that you have described rules for updating Target=20 >that are different from those for updating P-CPI. But it=20 >seems to me that is a distinction without a significant=20 >difference. For the recipient of the request, the two are=20 >used the same way, toward the same end. If anything I would=20 >view the rules for Target to be just a bug fix on P-CPI. You don't update P-CPI. It's inserted by the home proxy, and nothing else. The headers have differenct semantics. I don't see that as a bug. Maybe we could try to change the semantics of P-CPI, and re-define the header, but that was never my intention when I proposed to use P-CPI. Regards, Christer=20 > Paul >=20 > Christer Holmberg wrote: > > Hi John, > >=20 > >> I guess what still confuses me is, when both Target and P-CPI are=20 > >> used, which comes first, i.e., which represents the=20 > earlier target?=20 > >> When I read the draft, I thought Target was earlier. From various=20 > >> clarifying emails I now get the impression that Target is=20 > later. Can=20 > >> you confirm? > >=20 > > I am not sure what you mean by "earlier" target.=20 > >=20 > > Target, if present, always represents the current target. A=20 > receiving=20 > > entity that receives a request without a Target header has=20 > to assume=20 > > that the Request-URI represents the current target. When no Target=20 > > header is available on the request then the Target is=20 > inserted when a=20 > > reroute is performed. > >=20 > > P-CPI is ONLY used to maintain the R-URI which is rewritten by the=20 > > contact of the UAS. I.e. by the home proxy which is usually=20 > at the end=20 > > of a chain of proxies. > >=20 > > When both Target and P-CPI are used: Target always represents the=20 > > current target. P-CPI always represents the AOR received by=20 > the home=20 > > proxy which may in some cases be the same as the current=20 > target but it=20 > > may also be the last route (not equal to the current=20 > target) taken to=20 > > deliver the request. > >=20 > >> Picking up on Francois' point about History-Info, with the=20 > >> introduction of Target and P-CPI we do indeed have a lot=20 > of URIs, and=20 > >> of course History-Info can already convey all these URIs and any=20 > >> others. The difference is that History-Info does not give=20 > particular=20 > >> semantics to each of the URIs it conveys > >> - they are simply a succession of targets. > >=20 > > Yes, we agree with your analysis regarding History-Info. The=20 > > UA-loose-draft discusses further issues with using History-Info. > >=20 > >> With Target and P-CPI we are aiming to define specific=20 > semantics. I=20 > >> am concerned whether we will be able to define these semantics=20 > >> tightly enough to ensure consistent implementations. > >=20 > > Target always represents the current target. See above. > >=20 > > P-CPI does not represent the current target in all cases. See above. > >=20 > >> The more URIs we try to define, the harder it will be to=20 > assign each > > one a clearly distinguishable meaning. I hope the next=20 > draft will help. > >=20 > > In the next version of the draft I will remove as much as possible=20 > > about P-CPI, in order not to cause confusion. I will only keep some=20 > > text where I describe the semantical difference between=20 > Target and P-CPI. > >=20 > > I also do agree with one of your previous comments, that we should=20 > > clarify the meaning of all the URIs we're using - and that=20 > should be=20 > > done no matter if we adopt Target or not. > >=20 > > Regards. > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >>> -----Original Message----- > >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: 15 January 2008 08:48 > >>> To: Francois Audet > >>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > >>> Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > >>> via proxy > >>> > >>> > >>> Hi, > >>> > >>> P-CPI could probably be useful in some cases, in addition=20 > to Loose=20 > >>> Route/Target. And, as the draft says, P-CPI will still have > >> to be used > >>> in IMS, because there are procedures defined for it. > >>> > >>> However, again, the purpose of the draft was to provide an > >> alternative > >>> to the Loose Route alternative, and that alternative is=20 > Target only. > >>> > >>> I am working on an updated version of the draft to make that more=20 > >>> clear. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>>> Hum. I guess then P-Called-ID would then be useful with > >> Loose-route > >>>> as well (although now I'm thinking that History-Info covers it). > >>>> > >>>> I think explaining all that in great and precise details, with a=20 > >>>> concrete example would be very useful. > >>>> > >>>> And then we could compare P-Target with Loose-route.=20 > >>> > >>> > >>> > >>> > >>>>> -----Original Message----- > >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>>> Sent: Monday, January 14, 2008 03:56 > >>>>> To: Audet, Francois (SC100:3055) > >>>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; > >> Elwell, John > >>>>> Subject: RE: [Sip] RE: Delivering request-URI and > >>> parameters to UAS > >>>>> via proxy > >>>>> > >>>>> > >>>>> Hi Francois, > >>>>> > >>>>>> I think what you meant by Target was more the "Current"=20 > >>>>>> target as opposed to the Initiatl Target. > >>>>> Yes. > >>>>> =20 > >>>>>> And if that's the case, then I don't see why it is > >>> different from > >>>>>> P-Called-ID (although I might be missing something > >> with what the > >>>>>> P-Called_ID is supposed to be). > >>>>> In the draft we try to explain the difference. But, we are > >>>> working on > >>>>> the text to make it more clear. > >>>>> > >>>>> The P-CPI is inserted when the R-URI is rewritten by > >> the Contact > >>>>> address of the UAS. RFC3455 calls that operation > >>>> "retargeting", but we > >>>>> don't think that is the definition for retarget used in the=20 > >>>>> ua-loose-route draft, which says: > >>>>> > >>>>> "When a home proxy receives a request and accesses a > >>>> location service, > >>>>> the resulting contact(s) obtained from the location service are=20 > >>>>> considered the last hop in the route towards the entity > >>>> addressed by > >>>>> the Request-URI. Since that target, almost by definition, > >>>> can claim > >>>>> the identity of the URI prior to translation, the operation > >>>> is one of > >>>>> routing and not retargeting." > >>>>> > >>>>> So, if we follow the definitions in the ua-loose-route > >>> draft, P-CPI > >>>>> would be inserted due to a reroute - not retarget. > >>>>> > >>>>> But, no matter whether we call it retarget or reroute, > >>> the point is > >>>>> that the P-CPI is inserted when the R-URI is rewritten with the=20 > >>>>> Contact address of the UAS. The scope of Target is wider > >>> than that, > >>>>> and can be used in any retargeting situation. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 03:12:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Nk-0000w4-W0; Wed, 16 Jan 2008 03:12:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF3Nj-0000vx-CN for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Ni-0000vo-Ui for sip@ietf.org; Wed, 16 Jan 2008 03:12:18 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF3Ng-0007hM-M6 for sip@ietf.org; Wed, 16 Jan 2008 03:12:18 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 150882169C; Wed, 16 Jan 2008 09:12:13 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-43-478dbc5c7871 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DEC0B2156F; Wed, 16 Jan 2008 09:12:12 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 09:12:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Date: Wed, 16 Jan 2008 09:12:11 +0100 Message-ID: In-Reply-To: <478CEFB4.6070002@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQ References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Francois Audet" X-OriginalArrivalTime: 16 Jan 2008 08:12:12.0435 (UTC) FILETIME=[7F5CF630:01C85817] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Paul Kyzivat , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen,=20 >I think we'll also need a new response code: 4xx I'm confused, too many URIs in request >=20 >Seriously, a solution based on yet another header with an URI IMHO introduces more complexity/confusion than solving the=20 >issue is worth. >=20 >Better to limit the scope of the problem we're trying to=20 >solve and document the known limitations / use cases. If the=20 >problem is to deliver the request URI to a UAS which is=20 >registered with its home proxy, and there is a mechanism by=20 >which the proxy can detect support by the UAS, Jonathan's=20 >solution is fine.=20 I don't think that is the whole problem (if it was, P-Called-Party-ID would probably work just fine). To my understanding it is not necessarily the home proxy of the UAS which rewrites the Request-URI in the use-cases presented in the drafts. It can be another entity in the path - an entity which havs no clue about what the UAS supports or not. Regards, Christer > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens.com] > >> Sent: Tuesday, January 15, 2008 01:20 > >> To: Christer Holmberg; Audet, Francois (SC100:3055) > >> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat > >> Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > >> via proxy > >> > >> Christer, > >> > >> I guess what still confuses me is, when both Target and P-CPI are=20 > >> used, which comes first, i.e., which represents the=20 > earlier target?=20 > >> When I read the draft, I thought Target was earlier. From various=20 > >> clarifying emails I now get the impression that Target is=20 > later. Can=20 > >> you confirm? > >> > >> Picking up on Francois' point about History-Info, with the=20 > >> introduction of Target and P-CPI we do indeed have a lot=20 > of URIs, and=20 > >> of course History-Info can already convey all these URIs and any=20 > >> others. The difference is that History-Info does not give=20 > particular=20 > >> semantics to each of the URIs it conveys > >> - they are simply a succession of targets. > >> With Target and P-CPI we are aiming to define specific=20 > semantics. I=20 > >> am concerned whether we will be able to define these semantics=20 > >> tightly enough to ensure consistent implementations. The=20 > more URIs we=20 > >> try to define, the harder it will be to assign each one a clearly=20 > >> distinguishable meaning. I hope the next draft will help. > >> > >> John > >> > >> =20 > >>> -----Original Message----- > >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: 15 January 2008 08:48 > >>> To: Francois Audet > >>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John > >>> Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > >>> via proxy > >>> > >>> > >>> Hi, > >>> > >>> P-CPI could probably be useful in some cases, in addition=20 > to Loose=20 > >>> Route/Target. And, as the draft says, P-CPI will still have > >>> =20 > >> to be used > >> =20 > >>> in IMS, because there are procedures defined for it. > >>> > >>> However, again, the purpose of the draft was to provide an > >>> =20 > >> alternative > >> =20 > >>> to the Loose Route alternative, and that alternative is=20 > Target only. > >>> > >>> I am working on an updated version of the draft to make that more=20 > >>> clear. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> =20 > >>>> Hum. I guess then P-Called-ID would then be useful with > >>>> =20 > >> Loose-route > >> =20 > >>>> as well (although now I'm thinking that History-Info covers it). > >>>> > >>>> I think explaining all that in great and precise details, with a=20 > >>>> concrete example would be very useful. > >>>> > >>>> And then we could compare P-Target with Loose-route.=20 > >>>> =20 > >>> > >>> > >>> > >>> =20 > >>>>> -----Original Message----- > >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>>> Sent: Monday, January 14, 2008 03:56 > >>>>> To: Audet, Francois (SC100:3055) > >>>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; > >>>>> =20 > >> Elwell, John > >> =20 > >>>>> Subject: RE: [Sip] RE: Delivering request-URI and > >>>>> =20 > >>> parameters to UAS > >>> =20 > >>>>> via proxy > >>>>> > >>>>> > >>>>> Hi Francois, > >>>>> > >>>>> =20 > >>>>>> I think what you meant by Target was more the "Current"=20 > >>>>>> target as opposed to the Initiatl Target. > >>>>>> =20 > >>>>> Yes. > >>>>> =20 > >>>>> =20 > >>>>>> And if that's the case, then I don't see why it is > >>>>>> =20 > >>> different from > >>> =20 > >>>>>> P-Called-ID (although I might be missing something > >>>>>> =20 > >> with what the > >> =20 > >>>>>> P-Called_ID is supposed to be). > >>>>>> =20 > >>>>> In the draft we try to explain the difference. But, we are > >>>>> =20 > >>>> working on > >>>> =20 > >>>>> the text to make it more clear. > >>>>> > >>>>> The P-CPI is inserted when the R-URI is rewritten by > >>>>> =20 > >> the Contact > >> =20 > >>>>> address of the UAS. RFC3455 calls that operation > >>>>> =20 > >>>> "retargeting", but we > >>>> =20 > >>>>> don't think that is the definition for retarget used in the=20 > >>>>> ua-loose-route draft, which says: > >>>>> > >>>>> "When a home proxy receives a request and accesses a > >>>>> =20 > >>>> location service, > >>>> =20 > >>>>> the resulting contact(s) obtained from the location service are=20 > >>>>> considered the last hop in the route towards the entity > >>>>> =20 > >>>> addressed by > >>>> =20 > >>>>> the Request-URI. Since that target, almost by definition, > >>>>> =20 > >>>> can claim > >>>> =20 > >>>>> the identity of the URI prior to translation, the operation > >>>>> =20 > >>>> is one of > >>>> =20 > >>>>> routing and not retargeting." > >>>>> > >>>>> So, if we follow the definitions in the ua-loose-route > >>>>> =20 > >>> draft, P-CPI > >>> =20 > >>>>> would be inserted due to a reroute - not retarget. > >>>>> > >>>>> But, no matter whether we call it retarget or reroute, > >>>>> =20 > >>> the point is > >>> =20 > >>>>> that the P-CPI is inserted when the R-URI is rewritten with the=20 > >>>>> Contact address of the UAS. The scope of Target is wider > >>>>> =20 > >>> than that, > >>> =20 > >>>>> and can be used in any retargeting situation. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> =20 > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > > > =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 03:41:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3pO-0007qY-Fu; Wed, 16 Jan 2008 03:40:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF3pM-0007lN-Bf for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:40:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3pL-0007ir-P1 for sip@ietf.org; Wed, 16 Jan 2008 03:40:51 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF3pL-0002j2-8m for sip@ietf.org; Wed, 16 Jan 2008 03:40:51 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 742AD210DF; Wed, 16 Jan 2008 09:40:50 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-af-478dc31170ce Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D134121055; Wed, 16 Jan 2008 09:40:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 09:40:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jan 2008 09:40:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl> From: "Christer Holmberg" To: X-OriginalArrivalTime: 16 Jan 2008 08:40:48.0607 (UTC) FILETIME=[7E4806F0:01C8581B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Elwell, John" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet Subject: [Sip] Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, We've uploaded a new version (-01) of the Target draft. We've tried to make things more clear. I've also removed all text about P-Called-Party-ID, except from one chapter where we try to explain the semantical difference between Target and P-CPI. You can also find the draft from: http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri-del ivery-01.txt Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 04:25:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF4Wm-0006rW-FD; Wed, 16 Jan 2008 04:25:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF4Wl-0006pN-0i for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 04:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF4Wk-0006pF-KS for sip@ietf.org; Wed, 16 Jan 2008 04:25:42 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF4Wi-0000Yd-Px for sip@ietf.org; Wed, 16 Jan 2008 04:25:42 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUQ0007SCURHZ@siemenscomms.co.uk> for sip@ietf.org; Wed, 16 Jan 2008 09:25:39 +0000 (GMT) Date: Wed, 16 Jan 2008 09:25:39 +0000 From: "Elwell, John" In-reply-to: A To: Christer Holmberg , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft thread-index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet Subject: [Sip] RE: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, Thanks for this revision, which makes things somewhat clearer. I do have a couple of comments: 1. I am not sure I agree with the assertions in section 4 concerning issues with the mechanisms in loose-route. Taking example 1, the Route header field should contain enough entries to get you to the registered contact, not just to an intermediate proxy. Therefore this situation should not arise with a correctly implemented home proxy. It is not clear to me how example 2 could arise either, for similar reasons. The MGC case can be resolved by taking into account the option tag in the REGISTER request, or if it is permanently registered, through provisioning. 2. Comparing the mechanism proposed with the loose-route mechanism, my understanding is: a)When retargeting occurs, the loose-route mechanism places the new target in the Request URI. Your proposal places the new target in both the Request-URI and the Target header field. b) When rerouting, the loose-route mechanism places the new route (i.e., the registered contact) in the Route header field. Your proposal places the new route in the Request-URI (the latter as per RFC 3261). So the two mechanisms solve exactly the same problems using a slightly different mechanism. Correct? 3. How P-Called-Party-ID fits into this is not really relevant from an IETF perspective - it seems there are some 3GPP-specific situations where the contents of P-Called-Party-ID will not equal the contents of Target. Correct? 4. If my suggestion in point 1 above that the loose-route mechanism does not suffer from the problems suggested, then each mechanism will work and each addresses the same problem. So it is just down to a beauty contest between the two. Correct? John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 January 2008 08:41 > To: sip@ietf.org > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; Jeroen=20 > van Bemmel; Francois Audet > Subject: Delivering request-URI and parameters to UAS via=20 > proxy - new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 >=20 > Hi, >=20 > We've uploaded a new version (-01) of the Target draft. >=20 > We've tried to make things more clear. I've also removed all=20 > text about > P-Called-Party-ID, except from one chapter where we try to explain the > semantical difference between Target and P-CPI. >=20 > You can also find the draft from: > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > et-uri-del > ivery-01.txt >=20 > Regards, >=20 > Christer >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 06:06:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF65i-0005xy-A0; Wed, 16 Jan 2008 06:05:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF65h-0005xs-3b for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:05:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF65g-0005xk-Mu for sip@ietf.org; Wed, 16 Jan 2008 06:05:52 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF65e-0002d9-GO for sip@ietf.org; Wed, 16 Jan 2008 06:05:52 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C90E820A2E; Wed, 16 Jan 2008 12:05:49 +0100 (CET) X-AuditID: c1b4fb3c-ae794bb0000030cf-30-478de50d1741 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9DE252076F; Wed, 16 Jan 2008 12:05:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:05:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jan 2008 12:05:48 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcg References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <0D5F 89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , X-OriginalArrivalTime: 16 Jan 2008 11:05:49.0417 (UTC) FILETIME=[C05E4590:01C8582F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet Subject: [Sip] RE: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John,=20 >Thanks for this revision, which makes things somewhat=20 >clearer. I do have a couple of comments: >=20 >1. I am not sure I agree with the assertions in section 4=20 >concerning issues with the mechanisms in loose-route. Taking=20 >example 1, the Route header field should contain enough=20 >entries to get you to the registered contact, not just to an=20 >intermediate proxy. Therefore this situation should not arise=20 >with a correctly implemented home proxy. It is not clear to=20 >me how example 2 could arise either, for similar reasons. The=20 >MGC case can be resolved by taking into account the option=20 >tag in the REGISTER request, or if it is permanently=20 >registered, through provisioning. The examples are not meant to show bugs in the loose-route mechanism. They are meant to help people understand the limitations with the loose-route mechanism. =20 >2. Comparing the mechanism proposed with the loose-route=20 >mechanism, my understanding is: >a)When retargeting occurs, the loose-route mechanism places=20 >the new target in the Request URI. Your proposal places the=20 >new target in both the Request-URI and the Target header field. >b) When rerouting, the loose-route mechanism places the new=20 >route (i.e., the registered contact) in the Route header=20 >field. Your proposal places the new route in the Request-URI=20 >(the latter as per RFC 3261). >So the two mechanisms solve exactly the same problems using a=20 >slightly different mechanism. Correct? Yes. The two solutions intend to solve the same problem. =20 >3. How P-Called-Party-ID fits into this is not really=20 >relevant from an IETF perspective - it seems there are some=20 >3GPP-specific situations where the contents of=20 >P-Called-Party-ID will not equal the contents of Target. Correct? Correct. >4. If my suggestion in point 1 above that the loose-route=20 >mechanism does not suffer from the problems suggested, then=20 >each mechanism will work and each addresses the same problem.=20 >So it is just down to a beauty contest between the two. Correct? See question 1. We believe that our solution does not have the same limitations as the loose-route solution. But, again, both solutions intend to solve the same problem. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 16 January 2008 08:41 > > To: sip@ietf.org > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; Jeroen van=20 > > Bemmel; Francois Audet > > Subject: Delivering request-URI and parameters to UAS via=20 > proxy - new=20 > > version of the draft-holmberg-sip-target-uri-delivery draft > >=20 > >=20 > > Hi, > >=20 > > We've uploaded a new version (-01) of the Target draft. > >=20 > > We've tried to make things more clear. I've also removed all text=20 > > about P-Called-Party-ID, except from one chapter where we try to=20 > > explain the semantical difference between Target and P-CPI. > >=20 > > You can also find the draft from: > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > et-uri-del > > ivery-01.txt > >=20 > > Regards, > >=20 > > Christer > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 06:19:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6Iu-0004IJ-0V; Wed, 16 Jan 2008 06:19:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF6Ir-0004Be-Va for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:19:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6Ir-0004BS-ID for sip@ietf.org; Wed, 16 Jan 2008 06:19:29 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF6Ip-0002su-LH for sip@ietf.org; Wed, 16 Jan 2008 06:19:29 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUQ00783I4EKU@siemenscomms.co.uk> for sip@ietf.org; Wed, 16 Jan 2008 11:19:26 +0000 (GMT) Date: Wed, 16 Jan 2008 11:19:25 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft In-reply-to: A To: Christer Holmberg , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft thread-index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F 89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net> A X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, I hear what you are saying, but I don't really see that the points you raised in section 4 are real limitations of the loose route mechanism. John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 January 2008 11:06 > To: Elwell, John; sip@ietf.org > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > Subject: [Sip] RE: Delivering request-URI and parameters to=20 > UAS via proxy - new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 >=20 > Hi John,=20 >=20 > >Thanks for this revision, which makes things somewhat=20 > >clearer. I do have a couple of comments: > >=20 > >1. I am not sure I agree with the assertions in section 4=20 > >concerning issues with the mechanisms in loose-route. Taking=20 > >example 1, the Route header field should contain enough=20 > >entries to get you to the registered contact, not just to an=20 > >intermediate proxy. Therefore this situation should not arise=20 > >with a correctly implemented home proxy. It is not clear to=20 > >me how example 2 could arise either, for similar reasons. The=20 > >MGC case can be resolved by taking into account the option=20 > >tag in the REGISTER request, or if it is permanently=20 > >registered, through provisioning. >=20 > The examples are not meant to show bugs in the loose-route mechanism. > They are meant to help people understand the limitations with the > loose-route mechanism. > =20 > >2. Comparing the mechanism proposed with the loose-route=20 > >mechanism, my understanding is: > >a)When retargeting occurs, the loose-route mechanism places=20 > >the new target in the Request URI. Your proposal places the=20 > >new target in both the Request-URI and the Target header field. > >b) When rerouting, the loose-route mechanism places the new=20 > >route (i.e., the registered contact) in the Route header=20 > >field. Your proposal places the new route in the Request-URI=20 > >(the latter as per RFC 3261). > >So the two mechanisms solve exactly the same problems using a=20 > >slightly different mechanism. Correct? >=20 > Yes. The two solutions intend to solve the same problem. > =20 > >3. How P-Called-Party-ID fits into this is not really=20 > >relevant from an IETF perspective - it seems there are some=20 > >3GPP-specific situations where the contents of=20 > >P-Called-Party-ID will not equal the contents of Target. Correct? >=20 > Correct. >=20 > >4. If my suggestion in point 1 above that the loose-route=20 > >mechanism does not suffer from the problems suggested, then=20 > >each mechanism will work and each addresses the same problem.=20 > >So it is just down to a beauty contest between the two. Correct? >=20 > See question 1. >=20 > We believe that our solution does not have the same limitations as the > loose-route solution. But, again, both solutions intend to solve the > same problem. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: 16 January 2008 08:41 > > > To: sip@ietf.org > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; Jeroen van=20 > > > Bemmel; Francois Audet > > > Subject: Delivering request-URI and parameters to UAS via=20 > > proxy - new=20 > > > version of the draft-holmberg-sip-target-uri-delivery draft > > >=20 > > >=20 > > > Hi, > > >=20 > > > We've uploaded a new version (-01) of the Target draft. > > >=20 > > > We've tried to make things more clear. I've also removed all text=20 > > > about P-Called-Party-ID, except from one chapter where we try to=20 > > > explain the semantical difference between Target and P-CPI. > > >=20 > > > You can also find the draft from: > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > et-uri-del > > > ivery-01.txt > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 06:35:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6YD-000449-3I; Wed, 16 Jan 2008 06:35:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF6YB-00042A-FT for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:35:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6YB-000421-3v for sip@ietf.org; Wed, 16 Jan 2008 06:35:19 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF6YA-0007e4-E5 for sip@ietf.org; Wed, 16 Jan 2008 06:35:18 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m0GBZC37028213 for ; Wed, 16 Jan 2008 05:35:18 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 05:35:15 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:35:12 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Wed, 16 Jan 2008 12:35:12 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001B09604@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001B09071@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-index: AchWzqJNXVX4sjNuQSaW1d5oVZlILgBXedEA References: <5D1A7985295922448D5550C94DE2918001B09071@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 16 Jan 2008 11:35:12.0603 (UTC) FILETIME=[DB4F1AB0:01C85833] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) I am seeing consensus on the second draft....... .....that everyone is confused by the semantics applied to the various headers, and the mail exchange does not seem to be clearing it up. I urge Christer and Hans Erik to get a new version out as soon as possible in the hope of removing some of the confusion. Regards Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Monday, January 14, 2008 4:58 PM > To: sip@ietf.org > Subject: [Sip] Delivering request-URI and parameters to UAS via proxy >=20 > (As WG chair) >=20 > In fulfilment of our charter items of >=20 > Dec 2007 Delivering request-URI and parameters to UAS via proxy to > WGLC =20 > Feb 2008 Delivering request-URI and parameters to UAS via proxy to > IESG (PS) >=20 > We now have a couple of proposals on the table for solving=20 > the problem. >=20 > The original draft from Jonathan and which led to the=20 > creation of the charter items by the WG is unfortunately=20 > expired, but is at: >=20 > http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt >=20 > The alternative document from Christer, etc is at: >=20 > http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- > uri-delive > ry-00.txt >=20 > We obviously need to make a decision between the two=20 > approaches so please attempt to address the following=20 > specific points via the mailing > list: >=20 > 1) Problem cases: These are summarised in section 4.4 of > draft-rosenberg-sip-ua-loose-route-01 and from my read of the=20 > other draft, I don't believe that this draft adds any others.=20 > If you believe there are other cases that should be covered=20 > by the solution, then please identify them. If there is=20 > support on any new problem cases, I would encourage the=20 > authors of both drafts to add text concerning these problem cases. >=20 > 2) Clarifications: If for any reason you don't understand either > draft, or believe that there are technical issues that are=20 > not represented in the current draft, please post your=20 > questions / comments to the list. I would encourage authors=20 > of both drafts to revise as frequently as appropriate to=20 > reflect the current state of discussion. >=20 > 3) Support for either position. If you wish to indicate support for > either position please do so, but please accompany this is=20 > technical reasoning as to why you have this position, as that=20 > will help other members of the WG form a position. >=20 > I would encourage as much list discussion as possible before=20 > Philadelphia. I suspect we will need to have a discussion at=20 > the face-to-face meeting in Philadephia, but list discussion=20 > is essential prior to that. If we can solve this positions on=20 > list, then well and good, and even better (that is how we are=20 > meant to make decisions). >=20 > Regards >=20 >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 06:38:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6b9-00069x-0E; Wed, 16 Jan 2008 06:38:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF6b8-00069s-Fm for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:38:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6b8-00069j-3S for sip@ietf.org; Wed, 16 Jan 2008 06:38:22 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF6b7-0007j0-9Z for sip@ietf.org; Wed, 16 Jan 2008 06:38:21 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 974E220F99; Wed, 16 Jan 2008 12:38:20 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-d7-478decac6f8f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7061320067; Wed, 16 Jan 2008 12:38:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:38:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Wed, 16 Jan 2008 12:38:19 +0100 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE2918001B09604@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-Index: AchWzqJNXVX4sjNuQSaW1d5oVZlILgBXedEAAAHq++A= References: <5D1A7985295922448D5550C94DE2918001B09071@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE2918001B09604@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 16 Jan 2008 11:38:20.0192 (UTC) FILETIME=[4B1EEA00:01C85834] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, I submitted a new version earlier today. Regards, Christer=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 16. tammikuuta 2008 13:35 > To: sip@ietf.org > Subject: RE: [Sip] Delivering request-URI and parameters to=20 > UAS via proxy >=20 > (As WG chair) >=20 > I am seeing consensus on the second draft....... >=20 >=20 > .....that everyone is confused by the semantics applied to=20 > the various headers, and the mail exchange does not seem to=20 > be clearing it up. >=20 > I urge Christer and Hans Erik to get a new version out as=20 > soon as possible in the hope of removing some of the confusion. >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Monday, January 14, 2008 4:58 PM > > To: sip@ietf.org > > Subject: [Sip] Delivering request-URI and parameters to UAS=20 > via proxy > >=20 > > (As WG chair) > >=20 > > In fulfilment of our charter items of > >=20 > > Dec 2007 Delivering request-URI and parameters to UAS=20 > via proxy to > > WGLC =20 > > Feb 2008 Delivering request-URI and parameters to UAS=20 > via proxy to > > IESG (PS) > >=20 > > We now have a couple of proposals on the table for solving the=20 > > problem. > >=20 > > The original draft from Jonathan and which led to the=20 > creation of the=20 > > charter items by the WG is unfortunately expired, but is at: > >=20 > > http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt > >=20 > > The alternative document from Christer, etc is at: > >=20 > > http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- > > uri-delive > > ry-00.txt > >=20 > > We obviously need to make a decision between the two approaches so=20 > > please attempt to address the following specific points via the=20 > > mailing > > list: > >=20 > > 1) Problem cases: These are summarised in section 4.4 of > > draft-rosenberg-sip-ua-loose-route-01 and from my read of the other=20 > > draft, I don't believe that this draft adds any others. > > If you believe there are other cases that should be covered by the=20 > > solution, then please identify them. If there is support on any new=20 > > problem cases, I would encourage the authors of both drafts to add=20 > > text concerning these problem cases. > >=20 > > 2) Clarifications: If for any reason you don't understand either > > draft, or believe that there are technical issues that are not=20 > > represented in the current draft, please post your questions /=20 > > comments to the list. I would encourage authors of both drafts to=20 > > revise as frequently as appropriate to reflect the current state of=20 > > discussion. > >=20 > > 3) Support for either position. If you wish to indicate support for > > either position please do so, but please accompany this is=20 > technical=20 > > reasoning as to why you have this position, as that will help other=20 > > members of the WG form a position. > >=20 > > I would encourage as much list discussion as possible before=20 > > Philadelphia. I suspect we will need to have a discussion at the=20 > > face-to-face meeting in Philadephia, but list discussion is=20 > essential=20 > > prior to that. If we can solve this positions on list, then=20 > well and=20 > > good, and even better (that is how we are meant to make decisions). > >=20 > > Regards > >=20 > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 06:51:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6nL-0000vD-TT; Wed, 16 Jan 2008 06:50:59 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF6nK-0000uu-2r for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:50:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6nJ-0000um-NT for sip@ietf.org; Wed, 16 Jan 2008 06:50:57 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF6nI-00080w-Qo for sip@ietf.org; Wed, 16 Jan 2008 06:50:57 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2991E20FAD; Wed, 16 Jan 2008 12:50:56 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-77-478defa06b2f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 03F41206E5; Wed, 16 Jan 2008 12:50:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:50:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Date: Wed, 16 Jan 2008 12:50:54 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kA== References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , X-OriginalArrivalTime: 16 Jan 2008 11:50:55.0771 (UTC) FILETIME=[0D7B1EB0:01C85836] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I hear what you are saying, but I don't really see that the points you raised in section 4 are real limitations of the loose route mechanism. I think it is a limitation that an entity using the mechanism has to know whether the the next hop supports it or not, and that the mechanism can only be used if the subsequent hops support it. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 16 January 2008 11:06 > > To: Elwell, John; sip@ietf.org > > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > Subject: [Sip] RE: Delivering request-URI and parameters to UAS via=20 > > proxy - new version of the draft-holmberg-sip-target-uri-delivery=20 > > draft > >=20 > >=20 > > Hi John, > >=20 > > >Thanks for this revision, which makes things somewhat=20 > clearer. I do=20 > > >have a couple of comments: > > >=20 > > >1. I am not sure I agree with the assertions in section 4=20 > concerning=20 > > >issues with the mechanisms in loose-route. Taking example 1, the=20 > > >Route header field should contain enough entries to get you to the=20 > > >registered contact, not just to an intermediate proxy.=20 > Therefore this=20 > > >situation should not arise with a correctly implemented=20 > home proxy.=20 > > >It is not clear to me how example 2 could arise either,=20 > for similar=20 > > >reasons. The MGC case can be resolved by taking into account the=20 > > >option tag in the REGISTER request, or if it is permanently=20 > > >registered, through provisioning. > >=20 > > The examples are not meant to show bugs in the loose-route=20 > mechanism. > > They are meant to help people understand the limitations with the=20 > > loose-route mechanism. > > =20 > > >2. Comparing the mechanism proposed with the loose-route=20 > mechanism,=20 > > >my understanding is: > > >a)When retargeting occurs, the loose-route mechanism=20 > places the new=20 > > >target in the Request URI. Your proposal places the new target in=20 > > >both the Request-URI and the Target header field. > > >b) When rerouting, the loose-route mechanism places the new route=20 > > >(i.e., the registered contact) in the Route header field. Your=20 > > >proposal places the new route in the Request-URI (the=20 > latter as per=20 > > >RFC 3261). > > >So the two mechanisms solve exactly the same problems using a=20 > > >slightly different mechanism. Correct? > >=20 > > Yes. The two solutions intend to solve the same problem. > > =20 > > >3. How P-Called-Party-ID fits into this is not really=20 > relevant from=20 > > >an IETF perspective - it seems there are some 3GPP-specific=20 > > >situations where the contents of P-Called-Party-ID will=20 > not equal the=20 > > >contents of Target. Correct? > >=20 > > Correct. > >=20 > > >4. If my suggestion in point 1 above that the loose-route=20 > mechanism=20 > > >does not suffer from the problems suggested, then each=20 > mechanism will=20 > > >work and each addresses the same problem. > > >So it is just down to a beauty contest between the two. Correct? > >=20 > > See question 1. > >=20 > > We believe that our solution does not have the same=20 > limitations as the=20 > > loose-route solution. But, again, both solutions intend to=20 > solve the=20 > > same problem. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: 16 January 2008 08:41 > > > > To: sip@ietf.org > > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John;=20 > Jeroen van=20 > > > > Bemmel; Francois Audet > > > > Subject: Delivering request-URI and parameters to UAS via > > > proxy - new > > > > version of the draft-holmberg-sip-target-uri-delivery draft > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > We've uploaded a new version (-01) of the Target draft. > > > >=20 > > > > We've tried to make things more clear. I've also=20 > removed all text=20 > > > > about P-Called-Party-ID, except from one chapter where=20 > we try to=20 > > > > explain the semantical difference between Target and P-CPI. > > > >=20 > > > > You can also find the draft from: > > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > > et-uri-del > > > > ivery-01.txt > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 07:59:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7rN-0007Gr-OP; Wed, 16 Jan 2008 07:59:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF7rM-0007FS-8B for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:59:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7rL-0007FK-Rp for sip@ietf.org; Wed, 16 Jan 2008 07:59:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF7rL-0001J9-37 for sip@ietf.org; Wed, 16 Jan 2008 07:59:11 -0500 X-IronPort-AV: E=Sophos;i="4.24,293,1196658000"; d="scan'208";a="83496114" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2008 07:59:09 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GCx8GM028619; Wed, 16 Jan 2008 07:59:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GCx4ua010366; Wed, 16 Jan 2008 12:59:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 07:59:03 -0500 Received: from [10.86.240.6] ([10.86.240.6]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 07:59:03 -0500 Message-ID: <478DFF99.4090405@cisco.com> Date: Wed, 16 Jan 2008 07:59:05 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 12:59:03.0623 (UTC) FILETIME=[9207D570:01C8583F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5785; t=1200488348; x=1201352348; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Delivering=20request-UR I=20and=20parameters=20to=20UAS=20via=20proxy=0A=20-new=20ve rsion=20of=20the=20draft-holmberg-sip-target-uri-delivery=20 draft |Sender:=20 |To:=20Christer=20Holmberg=20; bh=rfnW60DPLotvYvsj2clzPsBPKOadCfzYvrE+O0Tzpi8=; b=okzWZ0BighuFpzpWf/tdazF7EJCeucMD6WzeQIofNwyPCGo4O7ppkRwZ2W ywiXZ+R6L+5wgPQO/gMUedKlbvwVwFvQJ1qAAwRFBo1rulzIh7PgxIMCpMgk 9IRAppr4gn; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Francois Audet , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >> I hear what you are saying, but I don't really see that the points you > raised in section 4 are real limitations of the loose route mechanism. > > I think it is a limitation that an entity using the mechanism has to > know whether the the next hop supports it or not, and that the mechanism > can only be used if the subsequent hops support it. In theory it is a problem. Its not at all clear that it is a problem in practice. That depends on whether this *will* be known in the places where the mechanism is used. AFAIK the loose route draft requires that the behavior of the next hop *be* known before the mechanism is used. So raising issues based on problems if it is used inappropriately are not valid. What *would* be valid are places where the mechanism is not used because support it not known, resulting is less functionality. I remain to be convinced there are any such cases. So I think these two mechanisms are getting close to be just being in a beauty contest. I think the crucial point in both of these is deciding when you are retargeting vs rerouting. Paul > Regards, > > Christer > > > > >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 16 January 2008 11:06 >>> To: Elwell, John; sip@ietf.org >>> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet >>> Subject: [Sip] RE: Delivering request-URI and parameters to UAS via >>> proxy - new version of the draft-holmberg-sip-target-uri-delivery >>> draft >>> >>> >>> Hi John, >>> >>>> Thanks for this revision, which makes things somewhat >> clearer. I do >>>> have a couple of comments: >>>> >>>> 1. I am not sure I agree with the assertions in section 4 >> concerning >>>> issues with the mechanisms in loose-route. Taking example 1, the >>>> Route header field should contain enough entries to get you to the >>>> registered contact, not just to an intermediate proxy. >> Therefore this >>>> situation should not arise with a correctly implemented >> home proxy. >>>> It is not clear to me how example 2 could arise either, >> for similar >>>> reasons. The MGC case can be resolved by taking into account the >>>> option tag in the REGISTER request, or if it is permanently >>>> registered, through provisioning. >>> The examples are not meant to show bugs in the loose-route >> mechanism. >>> They are meant to help people understand the limitations with the >>> loose-route mechanism. >>> >>>> 2. Comparing the mechanism proposed with the loose-route >> mechanism, >>>> my understanding is: >>>> a)When retargeting occurs, the loose-route mechanism >> places the new >>>> target in the Request URI. Your proposal places the new target in >>>> both the Request-URI and the Target header field. >>>> b) When rerouting, the loose-route mechanism places the new route >>>> (i.e., the registered contact) in the Route header field. Your >>>> proposal places the new route in the Request-URI (the >> latter as per >>>> RFC 3261). >>>> So the two mechanisms solve exactly the same problems using a >>>> slightly different mechanism. Correct? >>> Yes. The two solutions intend to solve the same problem. >>> >>>> 3. How P-Called-Party-ID fits into this is not really >> relevant from >>>> an IETF perspective - it seems there are some 3GPP-specific >>>> situations where the contents of P-Called-Party-ID will >> not equal the >>>> contents of Target. Correct? >>> Correct. >>> >>>> 4. If my suggestion in point 1 above that the loose-route >> mechanism >>>> does not suffer from the problems suggested, then each >> mechanism will >>>> work and each addresses the same problem. >>>> So it is just down to a beauty contest between the two. Correct? >>> See question 1. >>> >>> We believe that our solution does not have the same >> limitations as the >>> loose-route solution. But, again, both solutions intend to >> solve the >>> same problem. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: 16 January 2008 08:41 >>>>> To: sip@ietf.org >>>>> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; >> Jeroen van >>>>> Bemmel; Francois Audet >>>>> Subject: Delivering request-URI and parameters to UAS via >>>> proxy - new >>>>> version of the draft-holmberg-sip-target-uri-delivery draft >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We've uploaded a new version (-01) of the Target draft. >>>>> >>>>> We've tried to make things more clear. I've also >> removed all text >>>>> about P-Called-Party-ID, except from one chapter where >> we try to >>>>> explain the semantical difference between Target and P-CPI. >>>>> >>>>> You can also find the draft from: >>>>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ >>>>> et-uri-del >>>>> ivery-01.txt >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@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@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 08:02:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7uz-0000KL-F1; Wed, 16 Jan 2008 08:02:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF7ux-0000KG-Qt for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:02:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7ux-0000K8-HF for sip@ietf.org; Wed, 16 Jan 2008 08:02:55 -0500 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF7uv-00051J-LD for sip@ietf.org; Wed, 16 Jan 2008 08:02:55 -0500 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B7DA018056 for ; Wed, 16 Jan 2008 18:32:49 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id A7B9118053 for ; Wed, 16 Jan 2008 18:32:49 +0530 (IST) Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.182]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 18:32:52 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.181]) by HYD-MDP-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 18:32:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jan 2008 18:30:43 +0530 Message-ID: <24BCDE728664A5429097057C063C9D64027659E7@HYD-MKD-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Routers Thread-Index: AchYP7Et19bAOeyJQ1uG/D3LmEh2SAAABydx References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A<0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> <478DFF99.4090405@cisco.com> From: To: X-OriginalArrivalTime: 16 Jan 2008 13:02:51.0797 (UTC) FILETIME=[1A086C50:01C85840] X-Spam-Score: 2.6 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] SIP Routers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1491679590==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1491679590== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85840.19ECE0A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85840.19ECE0A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, Can some one suggest me info on SIP Routers. Are there any SIP Routers available in the market today? =20 Regards Kamal =20 ------_=_NextPart_001_01C85840.19ECE0A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] RE: Delivering request-URI and = parameters to UAS via proxy-new version of the = draft-holmberg-sip-target-uri-delivery draft=0A= =0A= =0A= =0A=
=0A=
Hi = there,
=0A=
Can some one suggest me info = on SIP Routers.
=0A=
Are there any SIP Routers = available in the market today?
=0A=
 
=0A=
Regards
=0A=
Kamal
=0A=
 
------_=_NextPart_001_01C85840.19ECE0A2-- --===============1491679590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1491679590==-- From sip-bounces@ietf.org Wed Jan 16 08:31:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8Mc-0005HX-7t; Wed, 16 Jan 2008 08:31:30 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF8MZ-0004pv-W5 for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:31:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8MZ-0004jI-F4 for sip@ietf.org; Wed, 16 Jan 2008 08:31:27 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF8MP-0005Qq-OK for sip@ietf.org; Wed, 16 Jan 2008 08:31:27 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUQ00BLCO6SQ4@szxga04-in.huawei.com> for sip@ietf.org; Wed, 16 Jan 2008 21:30:28 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUQ00BK3O6OO3@szxga04-in.huawei.com> for sip@ietf.org; Wed, 16 Jan 2008 21:30:27 +0800 (CST) Received: from htipl60927 ([10.18.3.113]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUQ004MJO6M6C@szxml03-in.huawei.com> for sip@ietf.org; Wed, 16 Jan 2008 21:30:24 +0800 (CST) Date: Wed, 16 Jan 2008 19:00:22 +0530 From: Srinivas To: sip@ietf.org Message-id: <00fb01c85843$f2be9ad0$7103120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchYQ/CtSaa2AGwwSomJEjhRwgkSQg== X-Spam-Score: 0.0 (/) X-Scan-Signature: b54c114e377ffd3b8a24b9a620caaf11 Subject: [Sip] regarding session modification X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1827363563==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1827363563== Content-type: multipart/alternative; boundary="Boundary_(ID_JAzyNXrpjuz7+16K8Ksb/g)" This is a multi-part message in MIME format. --Boundary_(ID_JAzyNXrpjuz7+16K8Ksb/g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi all, Consider the following scenarios. 1. C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK Now the SIP session is established b/w UAC and UAS. speechrecog resource is active on the established sip session C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK Offer/Answer fail for the new resource, TTS (speechsynth). 2. C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK Now the SIP session is established b/w UAC and UAS. speechrecog resource is active on the established sip session. C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK Offer/Answer fail for the for the existing ASR(speechrecog) resource also. 3. C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK Now the SIP session is established b/w UAC and UAS. speechrecog resource is active C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK C->S: ACK Now both speechrecog and speechsynth are active on the sip session C->S: INVITE (re-INVITE for removing speechsynth resource) S->C: 486 BUSY HERE What should be the behaviour of UAC in the above scenarios? Regds, Srinivas --Boundary_(ID_JAzyNXrpjuz7+16K8Ksb/g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi = all,

Consider the following = scenarios.

 

1. =

C->S: INVITE = (for speechrecog)

S->C: 200 = OK

C->S: = ACK

 

Now the SIP session is = established b/w UAC and UAS. speechrecog resource is active on the established sip = session

 

C->S: INVITE = (re-INVITE for adding speechsynth resource)

S->C: 200 OK =

Offer/Answer fail for the new = resource, TTS (speechsynth).

 

 

2. =

C->S: INVITE = (for speechrecog)

S->C: 200 = OK

C->S: = ACK

 

Now the SIP session is = established b/w UAC and UAS. speechrecog resource is active on the established sip = session.

 

C->S: INVITE = (re-INVITE for adding speechsynth resource)

S->C: 200 OK =

Offer/Answer fail for the for = the existing ASR(speechrecog) resource also.

 

3.

C->S: INVITE = (for speechrecog)

S->C: 200 = OK

C->S: = ACK

 

Now the SIP session is = established b/w UAC and UAS. speechrecog resource is active

 

C->S: INVITE = (re-INVITE for adding speechsynth resource)

S->C: 200 = OK

C->S: = ACK

 

Now both speechrecog and = speechsynth are active on the sip session

 

C->S: INVITE = (re-INVITE for removing speechsynth resource)

S->C: 486 = BUSY HERE

 

 

What should be the behaviour of = UAC in the above scenarios?

 

 

Regds,

Srinivas=

 

 

--Boundary_(ID_JAzyNXrpjuz7+16K8Ksb/g)-- --===============1827363563== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1827363563==-- From sip-bounces@ietf.org Wed Jan 16 08:36:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8RN-0001wj-Rh; Wed, 16 Jan 2008 08:36:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF8RM-0001wI-RJ for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:36:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8RM-0001vy-Gd for sip@ietf.org; Wed, 16 Jan 2008 08:36:24 -0500 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF8RJ-0005a6-1g for sip@ietf.org; Wed, 16 Jan 2008 08:36:24 -0500 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EA49018067 for ; Wed, 16 Jan 2008 19:06:16 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id D4EEF18053 for ; Wed, 16 Jan 2008 19:06:16 +0530 (IST) Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.182]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 19:06:19 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.181]) by HYD-MDP-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 19:06:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] regarding session modification Date: Wed, 16 Jan 2008 19:05:18 +0530 Message-ID: <24BCDE728664A5429097057C063C9D64027659E9@HYD-MKD-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] regarding session modification Thread-Index: AchYQ/CtSaa2AGwwSomJEjhRwgkSQgAALHr4 References: <00fb01c85843$f2be9ad0$7103120a@china.huawei.com> From: To: , X-OriginalArrivalTime: 16 Jan 2008 13:36:18.0511 (UTC) FILETIME=[C620ADF0:01C85844] X-Spam-Score: 1.8 (+) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0189643560==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0189643560== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85844.C5F6D904" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85844.C5F6D904 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the header field that is changed in all re-INVITEs. What is the value of this header field in each scenario? ________________________________ From: Srinivas [mailto:srinivasj@huawei.com] Sent: Wed 1/16/2008 7:00 PM To: sip@ietf.org Subject: [Sip] regarding session modification Hi all, Consider the following scenarios.=20 =20 1.=20 C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK =20 Now the SIP session is established b/w UAC and UAS. speechrecog resource = is active on the established sip session =20 C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK=20 Offer/Answer fail for the new resource, TTS (speechsynth). =20 =20 2.=20 C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK =20 Now the SIP session is established b/w UAC and UAS. speechrecog resource = is active on the established sip session. =20 C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK=20 Offer/Answer fail for the for the existing ASR(speechrecog) resource = also. =20 3. C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK =20 Now the SIP session is established b/w UAC and UAS. speechrecog resource = is active =20 C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK C->S: ACK =20 Now both speechrecog and speechsynth are active on the sip session =20 C->S: INVITE (re-INVITE for removing speechsynth resource) S->C: 486 BUSY HERE =20 =20 What should be the behaviour of UAC in the above scenarios? =20 =20 Regds, Srinivas =20 =20 ------_=_NextPart_001_01C85844.C5F6D904 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
What is the = header field that is changed in all re-INVITEs.
=0A=
What is the value of this = header field in each scenario?
=0A=

=0A=
=0A= From: Srinivas = [mailto:srinivasj@huawei.com]
Sent: Wed 1/16/2008 7:00 = PM
To: sip@ietf.org
Subject: [Sip] regarding session = modification

=0A=
=0A=
=0A=

Hi all,

=0A=

Consider the following = scenarios.

=0A=

 

=0A=

1. =

=0A=

C->S: = INVITE (for speechrecog)

=0A=

S->C: = 200 OK

=0A=

C->S: = ACK

=0A=

 

=0A=

Now the SIP session is = established b/w UAC and UAS. speechrecog resource is active on the = established sip session

=0A=

 

=0A=

C->S: = INVITE (re-INVITE for adding speechsynth resource)

=0A=

S->C: = 200 OK

=0A=

Offer/Answer fail for the new = resource, TTS (speechsynth).

=0A=

 

=0A=

 

=0A=

2. =

=0A=

C->S: = INVITE (for speechrecog)

=0A=

S->C: = 200 OK

=0A=

C->S: = ACK

=0A=

 

=0A=

Now the SIP session is = established b/w UAC and UAS. speechrecog resource is active on the = established sip session.

=0A=

 

=0A=

C->S: = INVITE (re-INVITE for adding speechsynth resource)

=0A=

S->C: = 200 OK

=0A=

Offer/Answer fail for the for = the existing ASR(speechrecog) resource also.

=0A=

 

=0A=

3.

=0A=

C->S: = INVITE (for speechrecog)

=0A=

S->C: = 200 OK

=0A=

C->S: = ACK

=0A=

 

=0A=

Now the SIP session is = established b/w UAC and UAS. speechrecog resource is = active

=0A=

 

=0A=

C->S: = INVITE (re-INVITE for adding speechsynth resource)

=0A=

S->C: = 200 OK

=0A=

C->S: = ACK

=0A=

 

=0A=

Now both speechrecog and = speechsynth are active on the sip session

=0A=

 

=0A=

C->S: = INVITE (re-INVITE for removing speechsynth = resource)

=0A=

S->C: = 486 BUSY HERE

=0A=

 

=0A=

 

=0A=

What should be the behaviour of = UAC in the above scenarios?

=0A=

 

=0A=

 

=0A=

Regds,

=0A=

Srinivas

=0A=

 

=0A=

 

------_=_NextPart_001_01C85844.C5F6D904-- --===============0189643560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0189643560==-- From sip-bounces@ietf.org Wed Jan 16 08:52:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8h7-00037Z-Dz; Wed, 16 Jan 2008 08:52:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF8h5-00036s-MJ for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:52:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8h5-00035W-AK for sip@ietf.org; Wed, 16 Jan 2008 08:52:39 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF8h4-0002VY-D6 for sip@ietf.org; Wed, 16 Jan 2008 08:52:39 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUQ00H3XP7L5M@siemenscomms.co.uk> for sip@ietf.org; Wed, 16 Jan 2008 13:52:33 +0000 (GMT) Date: Wed, 16 Jan 2008 13:52:32 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft In-reply-to: A To: Christer Holmberg , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft thread-index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kAAEi6eA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net> A <"C A9998CD 4A02 0D41 8654FCDEF4E7 07DF04173AE9"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> A X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, I don't think the entity using the mechanism needs to know about next hop support for the loose route mechanism - only whether the UAS supports it. If the UA registers, then the loose route draft provides an automatic mechanism. If the UA does not register, support would need to be indicated by provisioning. I am not sure this ranks as a significant limitation, since a certain amount of provisioning needs to be done anyway for UAs such as gateways that do not register. John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 January 2008 11:51 > To: Elwell, John; sip@ietf.org > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy -new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 >=20 > Hi,=20 >=20 > >I hear what you are saying, but I don't really see that the=20 > points you > raised in section 4 are real limitations of the loose route mechanism. >=20 > I think it is a limitation that an entity using the mechanism has to > know whether the the next hop supports it or not, and that=20 > the mechanism > can only be used if the subsequent hops support it. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: 16 January 2008 11:06 > > > To: Elwell, John; sip@ietf.org > > > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > > Subject: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via=20 > > > proxy - new version of the draft-holmberg-sip-target-uri-delivery=20 > > > draft > > >=20 > > >=20 > > > Hi John, > > >=20 > > > >Thanks for this revision, which makes things somewhat=20 > > clearer. I do=20 > > > >have a couple of comments: > > > >=20 > > > >1. I am not sure I agree with the assertions in section 4=20 > > concerning=20 > > > >issues with the mechanisms in loose-route. Taking example 1, the=20 > > > >Route header field should contain enough entries to get=20 > you to the=20 > > > >registered contact, not just to an intermediate proxy.=20 > > Therefore this=20 > > > >situation should not arise with a correctly implemented=20 > > home proxy.=20 > > > >It is not clear to me how example 2 could arise either,=20 > > for similar=20 > > > >reasons. The MGC case can be resolved by taking into account the=20 > > > >option tag in the REGISTER request, or if it is permanently=20 > > > >registered, through provisioning. > > >=20 > > > The examples are not meant to show bugs in the loose-route=20 > > mechanism. > > > They are meant to help people understand the limitations with the=20 > > > loose-route mechanism. > > > =20 > > > >2. Comparing the mechanism proposed with the loose-route=20 > > mechanism,=20 > > > >my understanding is: > > > >a)When retargeting occurs, the loose-route mechanism=20 > > places the new=20 > > > >target in the Request URI. Your proposal places the new=20 > target in=20 > > > >both the Request-URI and the Target header field. > > > >b) When rerouting, the loose-route mechanism places the=20 > new route=20 > > > >(i.e., the registered contact) in the Route header field. Your=20 > > > >proposal places the new route in the Request-URI (the=20 > > latter as per=20 > > > >RFC 3261). > > > >So the two mechanisms solve exactly the same problems using a=20 > > > >slightly different mechanism. Correct? > > >=20 > > > Yes. The two solutions intend to solve the same problem. > > > =20 > > > >3. How P-Called-Party-ID fits into this is not really=20 > > relevant from=20 > > > >an IETF perspective - it seems there are some 3GPP-specific=20 > > > >situations where the contents of P-Called-Party-ID will=20 > > not equal the=20 > > > >contents of Target. Correct? > > >=20 > > > Correct. > > >=20 > > > >4. If my suggestion in point 1 above that the loose-route=20 > > mechanism=20 > > > >does not suffer from the problems suggested, then each=20 > > mechanism will=20 > > > >work and each addresses the same problem. > > > >So it is just down to a beauty contest between the two. Correct? > > >=20 > > > See question 1. > > >=20 > > > We believe that our solution does not have the same=20 > > limitations as the=20 > > > loose-route solution. But, again, both solutions intend to=20 > > solve the=20 > > > same problem. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 16 January 2008 08:41 > > > > > To: sip@ietf.org > > > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John;=20 > > Jeroen van=20 > > > > > Bemmel; Francois Audet > > > > > Subject: Delivering request-URI and parameters to UAS via > > > > proxy - new > > > > > version of the draft-holmberg-sip-target-uri-delivery draft > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > We've uploaded a new version (-01) of the Target draft. > > > > >=20 > > > > > We've tried to make things more clear. I've also=20 > > removed all text=20 > > > > > about P-Called-Party-ID, except from one chapter where=20 > > we try to=20 > > > > > explain the semantical difference between Target and P-CPI. > > > > >=20 > > > > > You can also find the draft from: > > > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > > > et-uri-del > > > > > ivery-01.txt > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 09:32:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9Jx-0006He-M3; Wed, 16 Jan 2008 09:32:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF9Jw-0006Dc-Ha for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:32:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9Jw-0006DU-50 for sip@ietf.org; Wed, 16 Jan 2008 09:32:48 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9Jv-0004ml-06 for sip@ietf.org; Wed, 16 Jan 2008 09:32:48 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9F8642103C; Wed, 16 Jan 2008 15:32:11 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-21-478e156b905c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6594C208AD; Wed, 16 Jan 2008 15:32:11 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 15:32:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Date: Wed, 16 Jan 2008 15:32:10 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kAAEi6eAAABgSrA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.ne t> A <"C A9998CD 4A0 2 0D41 8654FCDEF4E7 07DF04173AE9"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , X-OriginalArrivalTime: 16 Jan 2008 14:32:11.0256 (UTC) FILETIME=[9484F780:01C8584C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, According to the UA-loose-route draft, every proxy in the path need to support the mechanism in order for the "current target" to be retained in the R-URI. A good example is the "Service Invocation" use case in the UA loose route draft. Maybe the "loose route" wording is confusing (I think it is also mentioned in the UA-loose-route draft that a better naming may be needed)? Also, maybe one can assume that a home proxy knows what entities not registering (MGCs etc) support. But, again, we are not only talking about home proxies. Regards, Christer=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 16. tammikuuta 2008 15:53 > To: Christer Holmberg; sip@ietf.org > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy -new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 > Christer, >=20 > I don't think the entity using the mechanism needs to know=20 > about next hop support for the loose route mechanism - only=20 > whether the UAS supports it. If the UA registers, then the=20 > loose route draft provides an automatic mechanism. If the UA=20 > does not register, support would need to be indicated by=20 > provisioning. I am not sure this ranks as a significant=20 > limitation, since a certain amount of provisioning needs to=20 > be done anyway for UAs such as gateways that do not register. >=20 > John=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 16 January 2008 11:51 > > To: Elwell, John; sip@ietf.org > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS=20 > > via proxy -new version of the=20 > draft-holmberg-sip-target-uri-delivery=20 > > draft > >=20 > >=20 > > Hi, > >=20 > > >I hear what you are saying, but I don't really see that the > > points you > > raised in section 4 are real limitations of the loose route=20 > mechanism. > >=20 > > I think it is a limitation that an entity using the=20 > mechanism has to=20 > > know whether the the next hop supports it or not, and that the=20 > > mechanism can only be used if the subsequent hops support it. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: 16 January 2008 11:06 > > > > To: Elwell, John; sip@ietf.org > > > > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > > > Subject: [Sip] RE: Delivering request-URI and parameters > > to UAS via > > > > proxy - new version of the=20 > draft-holmberg-sip-target-uri-delivery > > > > draft > > > >=20 > > > >=20 > > > > Hi John, > > > >=20 > > > > >Thanks for this revision, which makes things somewhat > > > clearer. I do > > > > >have a couple of comments: > > > > >=20 > > > > >1. I am not sure I agree with the assertions in section 4 > > > concerning > > > > >issues with the mechanisms in loose-route. Taking=20 > example 1, the=20 > > > > >Route header field should contain enough entries to get > > you to the > > > > >registered contact, not just to an intermediate proxy.=20 > > > Therefore this > > > > >situation should not arise with a correctly implemented > > > home proxy.=20 > > > > >It is not clear to me how example 2 could arise either, > > > for similar > > > > >reasons. The MGC case can be resolved by taking into=20 > account the=20 > > > > >option tag in the REGISTER request, or if it is permanently=20 > > > > >registered, through provisioning. > > > >=20 > > > > The examples are not meant to show bugs in the loose-route > > > mechanism. > > > > They are meant to help people understand the=20 > limitations with the=20 > > > > loose-route mechanism. > > > > =20 > > > > >2. Comparing the mechanism proposed with the loose-route > > > mechanism, > > > > >my understanding is: > > > > >a)When retargeting occurs, the loose-route mechanism > > > places the new > > > > >target in the Request URI. Your proposal places the new > > target in > > > > >both the Request-URI and the Target header field. > > > > >b) When rerouting, the loose-route mechanism places the > > new route > > > > >(i.e., the registered contact) in the Route header field. Your=20 > > > > >proposal places the new route in the Request-URI (the > > > latter as per > > > > >RFC 3261). > > > > >So the two mechanisms solve exactly the same problems using a=20 > > > > >slightly different mechanism. Correct? > > > >=20 > > > > Yes. The two solutions intend to solve the same problem. > > > > =20 > > > > >3. How P-Called-Party-ID fits into this is not really > > > relevant from > > > > >an IETF perspective - it seems there are some 3GPP-specific=20 > > > > >situations where the contents of P-Called-Party-ID will > > > not equal the > > > > >contents of Target. Correct? > > > >=20 > > > > Correct. > > > >=20 > > > > >4. If my suggestion in point 1 above that the loose-route > > > mechanism > > > > >does not suffer from the problems suggested, then each > > > mechanism will > > > > >work and each addresses the same problem. > > > > >So it is just down to a beauty contest between the=20 > two. Correct? > > > >=20 > > > > See question 1. > > > >=20 > > > > We believe that our solution does not have the same > > > limitations as the > > > > loose-route solution. But, again, both solutions intend to > > > solve the > > > > same problem. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: 16 January 2008 08:41 > > > > > > To: sip@ietf.org > > > > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > > > Jeroen van > > > > > > Bemmel; Francois Audet > > > > > > Subject: Delivering request-URI and parameters to UAS via > > > > > proxy - new > > > > > > version of the draft-holmberg-sip-target-uri-delivery draft > > > > > >=20 > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > We've uploaded a new version (-01) of the Target draft. > > > > > >=20 > > > > > > We've tried to make things more clear. I've also > > > removed all text > > > > > > about P-Called-Party-ID, except from one chapter where > > > we try to > > > > > > explain the semantical difference between Target and P-CPI. > > > > > >=20 > > > > > > You can also find the draft from: > > > > > >=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > > > > et-uri-del > > > > > > ivery-01.txt > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > Christer > > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 09:44:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9VB-0001Mw-Fz; Wed, 16 Jan 2008 09:44:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF9V9-0001EI-Iv for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:44:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9V9-0001E8-6T for sip@ietf.org; Wed, 16 Jan 2008 09:44:23 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9V8-00052P-0h for sip@ietf.org; Wed, 16 Jan 2008 09:44:23 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 309D921014; Wed, 16 Jan 2008 15:44:21 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-5f-478e18454c67 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 008552103A; Wed, 16 Jan 2008 15:44:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 15:44:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Date: Wed, 16 Jan 2008 15:44:18 +0100 Message-ID: In-Reply-To: <478DFF99.4090405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: AchYP5hu9rR5GqMpSNWcHUF30I666AAAIlag References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> <478DFF99.4090405@cisco.com > From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Jan 2008 14:44:19.0805 (UTC) FILETIME=[46C4B8D0:01C8584E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" , Francois Audet , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul,=20 >>>I hear what you are saying, but I don't really see that the points you >>>raised in section 4 are real limitations of the loose route mechanism. >>=20 >>I think it is a limitation that an entity using the mechanism has to=20 >>know whether the the next hop supports it or not, and that the=20 >>mechanism can only be used if the subsequent hops support it. >=20 >In theory it is a problem. Its not at all clear that it is a=20 >problem in practice. That depends on whether this *will* be=20 >known in the places where the mechanism is used. I don't think it's a theoretical problem. You may have next hop entities in different domains, belonging to different operators, assigned dynamically for each call (using DNS, load sharing etc), being updated with more/less capabilities very frequencly etc etc etc. So, I think there are lots of scenarios where it will simply be impossible for an entity to know what the next physical hop will support. Yes, an UA can indicate to its home proxy what it supports, but again I think it is important that we are not only talking about home proxies. And, if we are going to start making protocol design based on the fact that entities know what other entities support, why do we need option-tags, why do we need Require, why do we need SDP? Why don't we just assume everything is provisioned... I thought the idea behind SIP, and the whole internet model, was to NOT rely on provisioning. >AFAIK the loose route draft requires that the behavior of the next hop >*be* known before the mechanism is used. > >So raising issues based on problems if it is used inappropriately are not valid. Again, the examples are just there to explain the limitation. Also, the issue about possible services that may break is not related to inappropriately use of the mechanism. The entity that does trigger the service relying on the mechanism may very well know that the next hop supports it. But, the hop after the next hop, and/or the hop after the hop of the next hop, may not support it. So, somewhere in the chain the service relying on the mechanism will be "broken" - even if the hop that doesn't support the mechanism has nothing to do with the service as such. We think that limits the usability of the mechanism (again it has nothing to do with inappropriately use of the mechanism). >What *would* be valid are places where the mechanism is not used because support it not known, resulting is less=20 >functionality. I remain to be convinced there are any such cases. >=20 >So I think these two mechanisms are getting close to be just being in a beauty contest. >=20 >I think the crucial point in both of these is deciding when you are retargeting vs rerouting. Yes, I agree. We should get a clear defintion, once and for all. Regards, Christer > >=20 > >=20 > >=20 > >=20 > >>> -----Original Message----- > >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: 16 January 2008 11:06 > >>> To: Elwell, John; sip@ietf.org > >>> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > >>> Subject: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via=20 > >>> proxy - new version of the draft-holmberg-sip-target-uri-delivery > >>> draft > >>> > >>> > >>> Hi John, > >>> > >>>> Thanks for this revision, which makes things somewhat > >> clearer. I do > >>>> have a couple of comments: > >>>> > >>>> 1. I am not sure I agree with the assertions in section 4 > >> concerning > >>>> issues with the mechanisms in loose-route. Taking example 1, the=20 > >>>> Route header field should contain enough entries to get=20 > you to the=20 > >>>> registered contact, not just to an intermediate proxy. > >> Therefore this > >>>> situation should not arise with a correctly implemented > >> home proxy.=20 > >>>> It is not clear to me how example 2 could arise either, > >> for similar > >>>> reasons. The MGC case can be resolved by taking into account the=20 > >>>> option tag in the REGISTER request, or if it is permanently=20 > >>>> registered, through provisioning. > >>> The examples are not meant to show bugs in the loose-route > >> mechanism. > >>> They are meant to help people understand the limitations with the=20 > >>> loose-route mechanism. > >>> =20 > >>>> 2. Comparing the mechanism proposed with the loose-route > >> mechanism, > >>>> my understanding is: > >>>> a)When retargeting occurs, the loose-route mechanism > >> places the new > >>>> target in the Request URI. Your proposal places the new=20 > target in=20 > >>>> both the Request-URI and the Target header field. > >>>> b) When rerouting, the loose-route mechanism places the=20 > new route=20 > >>>> (i.e., the registered contact) in the Route header field. Your=20 > >>>> proposal places the new route in the Request-URI (the > >> latter as per > >>>> RFC 3261). > >>>> So the two mechanisms solve exactly the same problems using a=20 > >>>> slightly different mechanism. Correct? > >>> Yes. The two solutions intend to solve the same problem. > >>> =20 > >>>> 3. How P-Called-Party-ID fits into this is not really > >> relevant from > >>>> an IETF perspective - it seems there are some 3GPP-specific=20 > >>>> situations where the contents of P-Called-Party-ID will > >> not equal the > >>>> contents of Target. Correct? > >>> Correct. > >>> > >>>> 4. If my suggestion in point 1 above that the loose-route > >> mechanism > >>>> does not suffer from the problems suggested, then each > >> mechanism will > >>>> work and each addresses the same problem. > >>>> So it is just down to a beauty contest between the two. Correct? > >>> See question 1. > >>> > >>> We believe that our solution does not have the same > >> limitations as the > >>> loose-route solution. But, again, both solutions intend to > >> solve the > >>> same problem. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> > >>>>> -----Original Message----- > >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>>> Sent: 16 January 2008 08:41 > >>>>> To: sip@ietf.org > >>>>> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > >> Jeroen van > >>>>> Bemmel; Francois Audet > >>>>> Subject: Delivering request-URI and parameters to UAS via > >>>> proxy - new > >>>>> version of the draft-holmberg-sip-target-uri-delivery draft > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> We've uploaded a new version (-01) of the Target draft. > >>>>> > >>>>> We've tried to make things more clear. I've also > >> removed all text > >>>>> about P-Called-Party-ID, except from one chapter where > >> we try to > >>>>> explain the semantical difference between Target and P-CPI. > >>>>> > >>>>> You can also find the draft from: > >>>>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > >>>>> et-uri-del > >>>>> ivery-01.txt > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@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=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 09:45:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9WX-0002qF-Ja; Wed, 16 Jan 2008 09:45:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JF9WW-0002nX-2e for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 09:45:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9WV-0002ku-LX for sip@ietf.org; Wed, 16 Jan 2008 09:45:47 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF9WU-000540-TO for sip@ietf.org; Wed, 16 Jan 2008 09:45:47 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id B71FF7DFE; Wed, 16 Jan 2008 06:45:45 -0800 (PST) Received: from [192.168.0.100] (pool-71-240-224-250.fred.east.verizon.net [71.240.224.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 7E43D7DF8; Wed, 16 Jan 2008 06:45:43 -0800 (PST) Message-ID: <478E1897.8030905@joelhalpern.com> Date: Wed, 16 Jan 2008 09:45:43 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net>A <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=SPF_NEUTRAL X-Spam-Level: * X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Maybe I am missing something simple. But, as I said at the meeting when Jonathan's draft was discussed, the main problem I have with the proposed solution(s) relates to the distinction between retargeting and routing. This distinction seems to be central to both proposals. The description of the distinction looks clear enough in the abstract. But when I try to analyze how a proxy would actually know which operation it is performing, it is not clear. Sometimes I am sure it will "just work." But the description, and thinking about the wide range of actual things proxies do, leaves me very uncertain as to the clarity. So I would at least like to ask if other folks find the distinction sufficiently clear to be reliable for meeting the need. My own hope had been that this process would either clarify the distinction or provide a different distinction which was clearer. Again, I may be off in left field, but after reviewing the drafts again I felt I had to ask. Joel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 12:41:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCGa-0002aY-Ag; Wed, 16 Jan 2008 12:41:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFCGX-0002aC-Vf for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:41:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCGX-0002a4-LL for sip@ietf.org; Wed, 16 Jan 2008 12:41:29 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFCGV-0005K9-UX for sip@ietf.org; Wed, 16 Jan 2008 12:41:29 -0500 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 18:41:26 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 18:41:26 +0100 Received: from [10.229.8.45] ([10.229.8.45]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 18:41:25 +0100 Message-ID: <478E4256.7020306@telecomitalia.it> Date: Wed, 16 Jan 2008 18:43:50 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] Delivering request-URI and parameters to UAS via proxy - new version of the draft-holmberg-sip-target-uri-delivery draft References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl> In-Reply-To: X-OriginalArrivalTime: 16 Jan 2008 17:41:25.0138 (UTC) FILETIME=[03F5DF20:01C85867] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385929724==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1385929724== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030204030701000703000005" This is a cryptographically signed message in MIME format. --------------ms030204030701000703000005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > We've uploaded a new version (-01) of the Target draft. > > We've tried to make things more clear. I've also removed all text about > P-Called-Party-ID, except from one chapter where we try to explain the > semantical difference between Target and P-CPI. Thanks Christer, the new version is pretty clear about the difference between Target and P-Called-Party-ID. However, other than the semantic difference, I'd also add that the Target header could be used in a cross-domain registration case, when the registered contact for a specific URI is an AOR itself targeting a different domain. As far as I know, such a case is uncommon in current SIP deployments, but it could appear more frequently with P2PSIP overlays, e.g. when peers with limited connectivity make themselves globally reachable using P2P URIs (maybe temporary ones). -- Ciao, Enrico --------------ms030204030701000703000005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDgwMTE2MTc0MzUwWjAjBgkqhkiG9w0BCQQxFgQU0FwQE2DG sKAFvqb/jwXk1X0GBvUwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQPd6VvfAFUiymYqcyOQ3tBDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPd6VvfAFUiym YqcyOQ3tBDANBgkqhkiG9w0BAQEFAASCAQCMa8bpKYlatqUhF5JlNywgJauBorBuVC0adpaO NpovknmGfxKUkL6rIIsRwm20/XeLuqope8YceYvJb/zSfnFAHsQ+EkUfrwQVt/6DLrtJb/hl kpZftKtCiWxNy2PSJ2CyeEUsvRLGpb1fKahUJZKsD1bcRGskTdqn+KvGkSookXrSpyJcOQQw oW0HMP+9YatpQpO8IjMRWJQu9bvztBuK4S435JaFXmchIFhCH7c06nojSYLlw467lGiEAQ2u omA4lzGklcqznw5EUVrbG4f2EMEE6FrFUdRyqY932YoKh8X/EdzXKDy0EdjCAB2bRoJk7JJV oR0/TtBe9TX1MlGvAAAAAAAA --------------ms030204030701000703000005-- --===============1385929724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1385929724==-- From sip-bounces@ietf.org Wed Jan 16 13:15:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCnH-0004r0-2k; Wed, 16 Jan 2008 13:15:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFCnF-0004qv-NM for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 13:15:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFCnF-0004qn-C8 for sip@ietf.org; Wed, 16 Jan 2008 13:15:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFCnE-0004IO-Q0 for sip@ietf.org; Wed, 16 Jan 2008 13:15:17 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2008 10:14:50 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GIEnhu025364; Wed, 16 Jan 2008 10:14:49 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GIEnnl000553; Wed, 16 Jan 2008 18:14:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 10:14:47 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.89.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 10:14:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jan 2008 12:14:46 -0600 To: , From: "James M. Polk" Subject: Re: [Sip] SIP Routers In-Reply-To: <24BCDE728664A5429097057C063C9D64027659E7@HYD-MKD-MBX01.wip ro.com> References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FAC29E2C41B98A6A762007F5D0593C0E"@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> <478DFF99.4090405@cisco.com> <24BCDE728664A5429097057C063C9D64027659E7@HYD-MKD-MBX01.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jan 2008 18:14:47.0577 (UTC) FILETIME=[AD81D090:01C8586B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=781; t=1200507290; x=1201371290; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20SIP=20Routers |Sender:=20; bh=qz7ObIZHR8V/5H2JQg6IWPQHnvo090shJbTeo6hK24A=; b=uo6o7dk0ZnYgsPLp1hHu954vk1YB0g0mXOKO3m04lAKVbVq6tbpqRrKuuC 8LDeaZV+7KKvOMbzcYfmivtOh0eL87ylrX9zK7Pq93+WXZNFryPgkLksXnwk S0jnPvRuhw+DeKr1Onf7I0HBLlAB88e2wrwocLOxN1tU85SGw3jVo=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 07:00 AM 1/16/2008, kamalakar.mergu@wipro.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C85840.19ECE0A2" > >Hi there, >Can some one suggest me info on SIP Routers. >Are there any SIP Routers available in the market today? Kamal which OSI layer are you wanting these SIP Routers to be operating at (layer 3 or layer 7 or another layer)? > >Regards >Kamal > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 16 20:14:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFJK2-00031Q-Bm; Wed, 16 Jan 2008 20:13:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFJK0-00031K-8G for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 20:13:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFJJz-00031C-T2 for sip@ietf.org; Wed, 16 Jan 2008 20:13:31 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFJJy-0006ks-UJ for sip@ietf.org; Wed, 16 Jan 2008 20:13:31 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m0H1DLWP007428; Wed, 16 Jan 2008 19:13:21 -0600 (CST) Received: from cnexp02.bj.lucent.com ([135.252.8.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 19:13:20 -0600 Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.27]) by cnexp02.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 09:13:15 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] regarding session modification Date: Thu, 17 Jan 2008 09:12:15 +0800 Message-ID: <1F053F0D5C42184B9878C8D79BAE7D16296235@CNEXC1U03.BJ.LUCENT.COM> In-Reply-To: <00fb01c85843$f2be9ad0$7103120a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] regarding session modification Thread-Index: AchYQ/CtSaa2AGwwSomJEjhRwgkSQgAXkJkw From: "Zhang, Rocky Fan Wen \(Rocky\)" To: "Srinivas" , X-OriginalArrivalTime: 17 Jan 2008 01:13:15.0757 (UTC) FILETIME=[232609D0:01C858A6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.6 (/) X-Scan-Signature: ad122f56a92d6ccd133117ee8a4b1ff3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0409708769==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0409708769== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C858A6.22D347A5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C858A6.22D347A5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 My concerns: =20 1. SHOULD the called party reply with 200 OK if the negotiation fails? 2. Why the first two tries to add speechsynth resource failed but the third success? 3. As my understanding, if the re-negotiation fails, it will not affect the current media. =20 =20 Best Regards, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fanwen zhang FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D Tel: +86-532-88615493 Email:fanwenz@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ________________________________ From: Srinivas [mailto:srinivasj@huawei.com]=20 Sent: Wednesday, January 16, 2008 9:30 PM To: sip@ietf.org Subject: [Sip] regarding session modification Hi all, Consider the following scenarios.=20 =20 1.=20 C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK =20 Now the SIP session is established b/w UAC and UAS. speechrecog resource is active on the established sip session =20 C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK=20 Offer/Answer fail for the new resource, TTS (speechsynth). =20 =20 2.=20 C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK =20 Now the SIP session is established b/w UAC and UAS. speechrecog resource is active on the established sip session. =20 C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK=20 Offer/Answer fail for the for the existing ASR(speechrecog) resource also. =20 3. C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK =20 Now the SIP session is established b/w UAC and UAS. speechrecog resource is active =20 C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK C->S: ACK =20 Now both speechrecog and speechsynth are active on the sip session =20 C->S: INVITE (re-INVITE for removing speechsynth resource) S->C: 486 BUSY HERE =20 =20 What should be the behaviour of UAC in the above scenarios? =20 =20 Regds, Srinivas =20 =20 ------_=_NextPart_001_01C858A6.22D347A5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
My concerns:
 
1. SHOULD the called party reply with 200 OK if = the=20 negotiation fails?
2. Why the first two tries to add speechsynth = resource=20 failed but the third success?
3. As my=20 understanding, if the re-negotiation fails, it will not affect the = current=20 media.
 
 
Best Regards,
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fanwen zhang
FS5000 CPE IOT, Alcatel-Lucent = Qingdao,=20 R&D
Tel:=20 +86-532-88615493
Email:fanwenz@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 

From: Srinivas = [mailto:srinivasj@huawei.com]=20
Sent: Wednesday, January 16, 2008 9:30 PM
To:=20 sip@ietf.org
Subject: [Sip] regarding session=20 modification

Hi=20 all,

Consider=20 the following scenarios.

 

1.=20

C->S:=20 INVITE (for speechrecog)

S->C:=20 200 OK

C->S:=20 ACK

 

Now=20 the SIP session is established b/w UAC and UAS. speechrecog resource is = active=20 on the established sip session

 

C->S:=20 INVITE (re-INVITE for adding speechsynth=20 resource)

S->C:=20 200 OK

Offer/Answer=20 fail for the new resource, TTS = (speechsynth).

 

 

2.=20

C->S:=20 INVITE (for speechrecog)

S->C:=20 200 OK

C->S:=20 ACK

 

Now=20 the SIP session is established b/w UAC and UAS. speechrecog resource is = active=20 on the established sip session.

 

C->S:=20 INVITE (re-INVITE for adding speechsynth=20 resource)

S->C:=20 200 OK

Offer/Answer=20 fail for the for the existing ASR(speechrecog) resource=20 also.

 

3.

C->S:=20 INVITE (for speechrecog)

S->C:=20 200 OK

C->S:=20 ACK

 

Now=20 the SIP session is established b/w UAC and UAS. speechrecog resource is=20 active

 

C->S:=20 INVITE (re-INVITE for adding speechsynth=20 resource)

S->C:=20 200 OK

C->S:=20 ACK

 

Now=20 both speechrecog and speechsynth are active on the sip=20 session

 

C->S:=20 INVITE (re-INVITE for removing speechsynth=20 resource)

S->C:=20 486 BUSY HERE

 

 

What=20 should be the behaviour of UAC in the above=20 scenarios?

 

 

Regds,

Srinivas

 

 

------_=_NextPart_001_01C858A6.22D347A5-- --===============0409708769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0409708769==-- From sip-bounces@ietf.org Wed Jan 16 23:38:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMVx-0005Ic-Do; Wed, 16 Jan 2008 23:38:05 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFMVw-0005DJ-21 for sip-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 23:38:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMVv-0005Bh-A4 for sip@ietf.org; Wed, 16 Jan 2008 23:38:03 -0500 Received: from qmta07.emeryville.ca.mail.comcast.net ([76.96.30.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFMVu-0000xm-Sh for sip@ietf.org; Wed, 16 Jan 2008 23:38:03 -0500 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id e4Xf1Y00D0EPcho0A00W00; Thu, 17 Jan 2008 04:38:02 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id e4dh1Y00J0umElk8M00000; Thu, 17 Jan 2008 04:37:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=t4RvkCyGimRXhqs9rWkA:9 a=pWLNP1JpatsOfh537pQA:7 a=vsl7JBK5S1wA6yU42H0XmOYnrWMA:4 a=hPjdaMEvmhQA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m0H4c007004223 for ; Wed, 16 Jan 2008 23:38:00 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m0H4c0nU004219; Wed, 16 Jan 2008 23:38:00 -0500 Date: Wed, 16 Jan 2008 23:38:00 -0500 Message-Id: <200801170438.m0H4c0nU004219@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <00fb01c85843$f2be9ad0$7103120a@china.huawei.com> (srinivasj@huawei.com) Subject: Re: [Sip] regarding session modification References: <00fb01c85843$f2be9ad0$7103120a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Srinivas 1. C->S: INVITE (for speechrecog) S->C: 200 OK C->S: ACK Now the SIP session is established b/w UAC and UAS. speechrecog resource is active on the established sip session C->S: INVITE (re-INVITE for adding speechsynth resource) S->C: 200 OK Offer/Answer fail for the new resource, TTS (speechsynth). What? OK, you don't specify whether the re-INVITE contains an SDP offer, but it appears to do so as you've labeled it "for adding speechsynth resource". The S responds 200, but you then say "offer/answer fails for the new resource". If S determines that it cannot provide a usable answer, then it must reject the re-INVITE with a failure response. The 200 response indicates offer/answer success. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 02:59:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPeQ-0001wO-Db; Thu, 17 Jan 2008 02:59:02 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFPeO-0001wH-CQ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 02:59:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPeN-0001w5-St for sip@ietf.org; Thu, 17 Jan 2008 02:58:59 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFPeM-0004z9-Om for sip@ietf.org; Thu, 17 Jan 2008 02:58:59 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUS00C043I7F0@siemenscomms.co.uk> for sip@ietf.org; Thu, 17 Jan 2008 07:58:55 +0000 (GMT) Date: Thu, 17 Jan 2008 07:58:54 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft In-reply-to: A To: Christer Holmberg , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft thread-index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kAAEi6eAAABgSrAAJYH44A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, We still seem to have a disconnect in our understanding. See below. John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 January 2008 14:32 > To: Elwell, John; sip@ietf.org > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy-new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 >=20 > John, >=20 > According to the UA-loose-route draft, every proxy in the path need to > support the mechanism in order for the "current target" to be retained > in the R-URI. A good example is the "Service Invocation" use=20 > case in the > UA loose route draft. [JRE] The Service Invocation section in loose-route tells me nothing about proxies on the path. It simply talks about invocation of a service at the UAS. >=20 > Maybe the "loose route" wording is confusing (I think it is also > mentioned in the UA-loose-route draft that a better naming may be > needed)? >=20 > Also, maybe one can assume that a home proxy knows what entities not > registering (MGCs etc) support. But, again, we are not only talking > about home proxies. [JRE] Surely it is only the home proxy that takes an AoR and determines a contact URI to route to. Maybe my understanding of home proxy is different. >=20 > Regards, >=20 > Christer=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Sent: 16. tammikuuta 2008 15:53 > > To: Christer Holmberg; sip@ietf.org > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > > to UAS via proxy -new version of the=20 > > draft-holmberg-sip-target-uri-delivery draft > >=20 > > Christer, > >=20 > > I don't think the entity using the mechanism needs to know=20 > > about next hop support for the loose route mechanism - only=20 > > whether the UAS supports it. If the UA registers, then the=20 > > loose route draft provides an automatic mechanism. If the UA=20 > > does not register, support would need to be indicated by=20 > > provisioning. I am not sure this ranks as a significant=20 > > limitation, since a certain amount of provisioning needs to=20 > > be done anyway for UAs such as gateways that do not register. > >=20 > > John=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: 16 January 2008 11:51 > > > To: Elwell, John; sip@ietf.org > > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > > Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > > > via proxy -new version of the=20 > > draft-holmberg-sip-target-uri-delivery=20 > > > draft > > >=20 > > >=20 > > > Hi, > > >=20 > > > >I hear what you are saying, but I don't really see that the > > > points you > > > raised in section 4 are real limitations of the loose route=20 > > mechanism. > > >=20 > > > I think it is a limitation that an entity using the=20 > > mechanism has to=20 > > > know whether the the next hop supports it or not, and that the=20 > > > mechanism can only be used if the subsequent hops support it. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 16 January 2008 11:06 > > > > > To: Elwell, John; sip@ietf.org > > > > > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > > > > Subject: [Sip] RE: Delivering request-URI and parameters > > > to UAS via > > > > > proxy - new version of the=20 > > draft-holmberg-sip-target-uri-delivery > > > > > draft > > > > >=20 > > > > >=20 > > > > > Hi John, > > > > >=20 > > > > > >Thanks for this revision, which makes things somewhat > > > > clearer. I do > > > > > >have a couple of comments: > > > > > >=20 > > > > > >1. I am not sure I agree with the assertions in section 4 > > > > concerning > > > > > >issues with the mechanisms in loose-route. Taking=20 > > example 1, the=20 > > > > > >Route header field should contain enough entries to get > > > you to the > > > > > >registered contact, not just to an intermediate proxy.=20 > > > > Therefore this > > > > > >situation should not arise with a correctly implemented > > > > home proxy.=20 > > > > > >It is not clear to me how example 2 could arise either, > > > > for similar > > > > > >reasons. The MGC case can be resolved by taking into=20 > > account the=20 > > > > > >option tag in the REGISTER request, or if it is permanently=20 > > > > > >registered, through provisioning. > > > > >=20 > > > > > The examples are not meant to show bugs in the loose-route > > > > mechanism. > > > > > They are meant to help people understand the=20 > > limitations with the=20 > > > > > loose-route mechanism. > > > > > =20 > > > > > >2. Comparing the mechanism proposed with the loose-route > > > > mechanism, > > > > > >my understanding is: > > > > > >a)When retargeting occurs, the loose-route mechanism > > > > places the new > > > > > >target in the Request URI. Your proposal places the new > > > target in > > > > > >both the Request-URI and the Target header field. > > > > > >b) When rerouting, the loose-route mechanism places the > > > new route > > > > > >(i.e., the registered contact) in the Route header=20 > field. Your=20 > > > > > >proposal places the new route in the Request-URI (the > > > > latter as per > > > > > >RFC 3261). > > > > > >So the two mechanisms solve exactly the same=20 > problems using a=20 > > > > > >slightly different mechanism. Correct? > > > > >=20 > > > > > Yes. The two solutions intend to solve the same problem. > > > > > =20 > > > > > >3. How P-Called-Party-ID fits into this is not really > > > > relevant from > > > > > >an IETF perspective - it seems there are some 3GPP-specific=20 > > > > > >situations where the contents of P-Called-Party-ID will > > > > not equal the > > > > > >contents of Target. Correct? > > > > >=20 > > > > > Correct. > > > > >=20 > > > > > >4. If my suggestion in point 1 above that the loose-route > > > > mechanism > > > > > >does not suffer from the problems suggested, then each > > > > mechanism will > > > > > >work and each addresses the same problem. > > > > > >So it is just down to a beauty contest between the=20 > > two. Correct? > > > > >=20 > > > > > See question 1. > > > > >=20 > > > > > We believe that our solution does not have the same > > > > limitations as the > > > > > loose-route solution. But, again, both solutions intend to > > > > solve the > > > > > same problem. > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: 16 January 2008 08:41 > > > > > > > To: sip@ietf.org > > > > > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > > > > Jeroen van > > > > > > > Bemmel; Francois Audet > > > > > > > Subject: Delivering request-URI and parameters to UAS via > > > > > > proxy - new > > > > > > > version of the=20 > draft-holmberg-sip-target-uri-delivery draft > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi, > > > > > > >=20 > > > > > > > We've uploaded a new version (-01) of the Target draft. > > > > > > >=20 > > > > > > > We've tried to make things more clear. I've also > > > > removed all text > > > > > > > about P-Called-Party-ID, except from one chapter where > > > > we try to > > > > > > > explain the semantical difference between Target=20 > and P-CPI. > > > > > > >=20 > > > > > > > You can also find the draft from: > > > > > > >=20 > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > > > > > et-uri-del > > > > > > > ivery-01.txt > > > > > > >=20 > > > > > > > Regards, > > > > > > >=20 > > > > > > > Christer > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on=20 > > current sip Use=20 > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 05:54:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSOO-0000Hv-C6; Thu, 17 Jan 2008 05:54:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFSON-0000HW-12 for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 05:54:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSOM-0000HD-JW for sip@ietf.org; Thu, 17 Jan 2008 05:54:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFSOL-0001Rz-8l for sip@ietf.org; Thu, 17 Jan 2008 05:54:38 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4BC5E20F42; Thu, 17 Jan 2008 11:54:36 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-c2-478f33ec0b27 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 21F8420E81; Thu, 17 Jan 2008 11:54:36 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 11:54:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft Date: Thu, 17 Jan 2008 11:54:34 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kAAEi6eAAABgSrAAJYH44AABmDAw References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemens .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , X-OriginalArrivalTime: 17 Jan 2008 10:54:35.0944 (UTC) FILETIME=[595C3280:01C858F7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >>According to the UA-loose-route draft, every proxy in the path need to >>support the mechanism in order for the "current target" to be retained >>in the R-URI. A good example is the "Service Invocation" use case in=20 >>the UA loose route draft. >[JRE] The Service Invocation section in loose-route tells me=20 >nothing about proxies on the path. It simply talks about=20 >invocation of a service at the UAS. This is what the loose draft says: "5. Proposed Solution The proposed solution is simple. When handling a request, a proxy only rewrites the Request-URI when performing a retargeting operation. If, instead, the proxy is trying to route the request via some entity (whether its a proxy or UA) to reach the target, the Request-URI is retained, and Route header fields are pushed into the request to reach the target. etc." This applies to ALL proxies on the path, otherwise one will not always find the current target (service invocation uri) in the Request-URI.=20 =20 >>Maybe the "loose route" wording is confusing (I think it is also=20 >>mentioned in the UA-loose-route draft that a better naming may be=20 >>needed)? >>=20 >>Also, maybe one can assume that a home proxy knows what entities not=20 >>registering (MGCs etc) support. But, again, we are not only talking=20 >>about home proxies. >[JRE] Surely it is only the home proxy that takes an AoR and determines a contact URI to route to. Maybe my understanding of home proxy is different. So, what is your understanding? Regards, Christer > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 16. tammikuuta 2008 15:53 > > > To: Christer Holmberg; sip@ietf.org > > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > > Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > > > via proxy -new version of the=20 > draft-holmberg-sip-target-uri-delivery=20 > > > draft > > >=20 > > > Christer, > > >=20 > > > I don't think the entity using the mechanism needs to know about=20 > > > next hop support for the loose route mechanism - only whether the=20 > > > UAS supports it. If the UA registers, then the loose route draft=20 > > > provides an automatic mechanism. If the UA does not register,=20 > > > support would need to be indicated by provisioning. I am not sure=20 > > > this ranks as a significant limitation, since a certain amount of=20 > > > provisioning needs to be done anyway for UAs such as=20 > gateways that=20 > > > do not register. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: 16 January 2008 11:51 > > > > To: Elwell, John; sip@ietf.org > > > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > > > Subject: RE: [Sip] RE: Delivering request-URI and > > parameters to UAS > > > > via proxy -new version of the > > > draft-holmberg-sip-target-uri-delivery > > > > draft > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > >I hear what you are saying, but I don't really see that the > > > > points you > > > > raised in section 4 are real limitations of the loose route > > > mechanism. > > > >=20 > > > > I think it is a limitation that an entity using the > > > mechanism has to > > > > know whether the the next hop supports it or not, and that the=20 > > > > mechanism can only be used if the subsequent hops support it. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: 16 January 2008 11:06 > > > > > > To: Elwell, John; sip@ietf.org > > > > > > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > > > > > Subject: [Sip] RE: Delivering request-URI and parameters > > > > to UAS via > > > > > > proxy - new version of the > > > draft-holmberg-sip-target-uri-delivery > > > > > > draft > > > > > >=20 > > > > > >=20 > > > > > > Hi John, > > > > > >=20 > > > > > > >Thanks for this revision, which makes things somewhat > > > > > clearer. I do > > > > > > >have a couple of comments: > > > > > > >=20 > > > > > > >1. I am not sure I agree with the assertions in section 4 > > > > > concerning > > > > > > >issues with the mechanisms in loose-route. Taking > > > example 1, the > > > > > > >Route header field should contain enough entries to get > > > > you to the > > > > > > >registered contact, not just to an intermediate proxy.=20 > > > > > Therefore this > > > > > > >situation should not arise with a correctly implemented > > > > > home proxy.=20 > > > > > > >It is not clear to me how example 2 could arise either, > > > > > for similar > > > > > > >reasons. The MGC case can be resolved by taking into > > > account the > > > > > > >option tag in the REGISTER request, or if it is=20 > permanently=20 > > > > > > >registered, through provisioning. > > > > > >=20 > > > > > > The examples are not meant to show bugs in the loose-route > > > > > mechanism. > > > > > > They are meant to help people understand the > > > limitations with the > > > > > > loose-route mechanism. > > > > > > =20 > > > > > > >2. Comparing the mechanism proposed with the loose-route > > > > > mechanism, > > > > > > >my understanding is: > > > > > > >a)When retargeting occurs, the loose-route mechanism > > > > > places the new > > > > > > >target in the Request URI. Your proposal places the new > > > > target in > > > > > > >both the Request-URI and the Target header field. > > > > > > >b) When rerouting, the loose-route mechanism places the > > > > new route > > > > > > >(i.e., the registered contact) in the Route header > > field. Your > > > > > > >proposal places the new route in the Request-URI (the > > > > > latter as per > > > > > > >RFC 3261). > > > > > > >So the two mechanisms solve exactly the same > > problems using a > > > > > > >slightly different mechanism. Correct? > > > > > >=20 > > > > > > Yes. The two solutions intend to solve the same problem. > > > > > > =20 > > > > > > >3. How P-Called-Party-ID fits into this is not really > > > > > relevant from > > > > > > >an IETF perspective - it seems there are some=20 > 3GPP-specific=20 > > > > > > >situations where the contents of P-Called-Party-ID will > > > > > not equal the > > > > > > >contents of Target. Correct? > > > > > >=20 > > > > > > Correct. > > > > > >=20 > > > > > > >4. If my suggestion in point 1 above that the loose-route > > > > > mechanism > > > > > > >does not suffer from the problems suggested, then each > > > > > mechanism will > > > > > > >work and each addresses the same problem. > > > > > > >So it is just down to a beauty contest between the > > > two. Correct? > > > > > >=20 > > > > > > See question 1. > > > > > >=20 > > > > > > We believe that our solution does not have the same > > > > > limitations as the > > > > > > loose-route solution. But, again, both solutions intend to > > > > > solve the > > > > > > same problem. > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > Christer > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > > Sent: 16 January 2008 08:41 > > > > > > > > To: sip@ietf.org > > > > > > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > > > > > Jeroen van > > > > > > > > Bemmel; Francois Audet > > > > > > > > Subject: Delivering request-URI and parameters=20 > to UAS via > > > > > > > proxy - new > > > > > > > > version of the > > draft-holmberg-sip-target-uri-delivery draft > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi, > > > > > > > >=20 > > > > > > > > We've uploaded a new version (-01) of the Target draft. > > > > > > > >=20 > > > > > > > > We've tried to make things more clear. I've also > > > > > removed all text > > > > > > > > about P-Called-Party-ID, except from one chapter where > > > > > we try to > > > > > > > > explain the semantical difference between Target > > and P-CPI. > > > > > > > >=20 > > > > > > > > You can also find the draft from: > > > > > > > >=20 > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > > > > > > et-uri-del > > > > > > > > ivery-01.txt > > > > > > > >=20 > > > > > > > > Regards, > > > > > > > >=20 > > > > > > > > Christer > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > > > sipping@ietf.org for new developments on the > > application of sip > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 06:14:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSh9-0000Df-63; Thu, 17 Jan 2008 06:14:03 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFSh7-00008l-2G for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 06:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFSh6-00008X-M5 for sip@ietf.org; Thu, 17 Jan 2008 06:14:00 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFSh4-00088Q-8d for sip@ietf.org; Thu, 17 Jan 2008 06:14:00 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUS0008TCEPVL@siemenscomms.co.uk> for sip@ietf.org; Thu, 17 Jan 2008 11:11:13 +0000 (GMT) Date: Thu, 17 Jan 2008 11:11:12 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft In-reply-to: A To: Christer Holmberg , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0593EB2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft thread-index: AchXnY+F82ywc0SeQiGSlvvV9WnM7QAZ7COQAAVV9CAAASbeoAAD/kcgAACRbVAAALp+kAAEi6eAAABgSrAAJYH44AABmDAwAAUz5DA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemens.net> A <"CA9998CD4A 0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> A X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 17 January 2008 10:55 > To: Elwell, John; sip@ietf.org > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > Subject: RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy-new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 >=20 > >>According to the UA-loose-route draft, every proxy in the=20 > path need to >=20 > >>support the mechanism in order for the "current target" to=20 > be retained >=20 > >>in the R-URI. A good example is the "Service Invocation"=20 > use case in=20 > >>the UA loose route draft. > >[JRE] The Service Invocation section in loose-route tells me=20 > >nothing about proxies on the path. It simply talks about=20 > >invocation of a service at the UAS. >=20 > This is what the loose draft says: >=20 > "5. Proposed Solution >=20 > The proposed solution is simple. When handling a request, a proxy > only rewrites the Request-URI when performing a retargeting > operation. If, instead, the proxy is trying to route the=20 > request via > some entity (whether its a proxy or UA) to reach the target, the > Request-URI is retained, and Route header fields are=20 > pushed into the > request to reach the target. >=20 > etc." >=20 > This applies to ALL proxies on the path, otherwise one will not always > find the current target (service invocation uri) in the Request-URI.=20 [JRE] Yes, but it doesn suggest to me that the proxies you need to route through are going to perform service invocation, so the fact that the information needed for service invocation is in the Request-URI should not be a concern for those proxies - they will do what any good proxy will do - route on the contents of the Route header field. Service information in the Request-URI is for the UAS. John > =20 > >>Maybe the "loose route" wording is confusing (I think it is also=20 > >>mentioned in the UA-loose-route draft that a better naming may be=20 > >>needed)? > >>=20 > >>Also, maybe one can assume that a home proxy knows what=20 > entities not=20 > >>registering (MGCs etc) support. But, again, we are not only talking=20 > >>about home proxies. > >[JRE] Surely it is only the home proxy that takes an AoR and=20 > determines > a contact URI to route to. Maybe my understanding of home proxy is > different. >=20 > So, what is your understanding? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 16. tammikuuta 2008 15:53 > > > > To: Christer Holmberg; sip@ietf.org > > > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > > > Subject: RE: [Sip] RE: Delivering request-URI and=20 > > parameters to UAS=20 > > > > via proxy -new version of the=20 > > draft-holmberg-sip-target-uri-delivery=20 > > > > draft > > > >=20 > > > > Christer, > > > >=20 > > > > I don't think the entity using the mechanism needs to=20 > know about=20 > > > > next hop support for the loose route mechanism - only=20 > whether the=20 > > > > UAS supports it. If the UA registers, then the loose=20 > route draft=20 > > > > provides an automatic mechanism. If the UA does not register,=20 > > > > support would need to be indicated by provisioning. I=20 > am not sure=20 > > > > this ranks as a significant limitation, since a certain=20 > amount of=20 > > > > provisioning needs to be done anyway for UAs such as=20 > > gateways that=20 > > > > do not register. > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 16 January 2008 11:51 > > > > > To: Elwell, John; sip@ietf.org > > > > > Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > > > > Subject: RE: [Sip] RE: Delivering request-URI and > > > parameters to UAS > > > > > via proxy -new version of the > > > > draft-holmberg-sip-target-uri-delivery > > > > > draft > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > >I hear what you are saying, but I don't really see that the > > > > > points you > > > > > raised in section 4 are real limitations of the loose route > > > > mechanism. > > > > >=20 > > > > > I think it is a limitation that an entity using the > > > > mechanism has to > > > > > know whether the the next hop supports it or not, and=20 > that the=20 > > > > > mechanism can only be used if the subsequent hops support it. > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: 16 January 2008 11:06 > > > > > > > To: Elwell, John; sip@ietf.org > > > > > > > Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > > > > > > Subject: [Sip] RE: Delivering request-URI and parameters > > > > > to UAS via > > > > > > > proxy - new version of the > > > > draft-holmberg-sip-target-uri-delivery > > > > > > > draft > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi John, > > > > > > >=20 > > > > > > > >Thanks for this revision, which makes things somewhat > > > > > > clearer. I do > > > > > > > >have a couple of comments: > > > > > > > >=20 > > > > > > > >1. I am not sure I agree with the assertions in section 4 > > > > > > concerning > > > > > > > >issues with the mechanisms in loose-route. Taking > > > > example 1, the > > > > > > > >Route header field should contain enough entries to get > > > > > you to the > > > > > > > >registered contact, not just to an intermediate proxy.=20 > > > > > > Therefore this > > > > > > > >situation should not arise with a correctly implemented > > > > > > home proxy.=20 > > > > > > > >It is not clear to me how example 2 could arise either, > > > > > > for similar > > > > > > > >reasons. The MGC case can be resolved by taking into > > > > account the > > > > > > > >option tag in the REGISTER request, or if it is=20 > > permanently=20 > > > > > > > >registered, through provisioning. > > > > > > >=20 > > > > > > > The examples are not meant to show bugs in the loose-route > > > > > > mechanism. > > > > > > > They are meant to help people understand the > > > > limitations with the > > > > > > > loose-route mechanism. > > > > > > > =20 > > > > > > > >2. Comparing the mechanism proposed with the loose-route > > > > > > mechanism, > > > > > > > >my understanding is: > > > > > > > >a)When retargeting occurs, the loose-route mechanism > > > > > > places the new > > > > > > > >target in the Request URI. Your proposal places the new > > > > > target in > > > > > > > >both the Request-URI and the Target header field. > > > > > > > >b) When rerouting, the loose-route mechanism places the > > > > > new route > > > > > > > >(i.e., the registered contact) in the Route header > > > field. Your > > > > > > > >proposal places the new route in the Request-URI (the > > > > > > latter as per > > > > > > > >RFC 3261). > > > > > > > >So the two mechanisms solve exactly the same > > > problems using a > > > > > > > >slightly different mechanism. Correct? > > > > > > >=20 > > > > > > > Yes. The two solutions intend to solve the same problem. > > > > > > > =20 > > > > > > > >3. How P-Called-Party-ID fits into this is not really > > > > > > relevant from > > > > > > > >an IETF perspective - it seems there are some=20 > > 3GPP-specific=20 > > > > > > > >situations where the contents of P-Called-Party-ID will > > > > > > not equal the > > > > > > > >contents of Target. Correct? > > > > > > >=20 > > > > > > > Correct. > > > > > > >=20 > > > > > > > >4. If my suggestion in point 1 above that the loose-route > > > > > > mechanism > > > > > > > >does not suffer from the problems suggested, then each > > > > > > mechanism will > > > > > > > >work and each addresses the same problem. > > > > > > > >So it is just down to a beauty contest between the > > > > two. Correct? > > > > > > >=20 > > > > > > > See question 1. > > > > > > >=20 > > > > > > > We believe that our solution does not have the same > > > > > > limitations as the > > > > > > > loose-route solution. But, again, both solutions intend to > > > > > > solve the > > > > > > > same problem. > > > > > > >=20 > > > > > > > Regards, > > > > > > >=20 > > > > > > > Christer > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > > > Sent: 16 January 2008 08:41 > > > > > > > > > To: sip@ietf.org > > > > > > > > > Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > > > > > > Jeroen van > > > > > > > > > Bemmel; Francois Audet > > > > > > > > > Subject: Delivering request-URI and parameters=20 > > to UAS via > > > > > > > > proxy - new > > > > > > > > > version of the > > > draft-holmberg-sip-target-uri-delivery draft > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi, > > > > > > > > >=20 > > > > > > > > > We've uploaded a new version (-01) of the=20 > Target draft. > > > > > > > > >=20 > > > > > > > > > We've tried to make things more clear. I've also > > > > > > removed all text > > > > > > > > > about P-Called-Party-ID, except from one chapter where > > > > > > we try to > > > > > > > > > explain the semantical difference between Target > > > and P-CPI. > > > > > > > > >=20 > > > > > > > > > You can also find the draft from: > > > > > > > > >=20 > > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > > > > > > > > et-uri-del > > > > > > > > > ivery-01.txt > > > > > > > > >=20 > > > > > > > > > Regards, > > > > > > > > >=20 > > > > > > > > > Christer > > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP=20 > > Protocol Use=20 > > > > > > > sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > > > sipping@ietf.org for new developments on the > > > application of sip > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > > > sipping@ietf.org for new developments on the=20 > > application of sip > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 14:14:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaB2-00044d-IH; Thu, 17 Jan 2008 14:13:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFaB1-00044X-2m for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 14:13:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaB0-00044P-Ou for sip@ietf.org; Thu, 17 Jan 2008 14:13:22 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFaAy-0002z9-Np for sip@ietf.org; Thu, 17 Jan 2008 14:13:22 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0HJDGTO023940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 17 Jan 2008 13:13:18 -0600 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 17 Jan 2008 13:13:08 -0600 To: IETF SIP List X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The ongoing discussion around parameter passing mechanisms is getting wrapped up in some concepts that we really haven't yet described well enough to be communicating clearly. This message is an attempt to develop a better understanding of the basic problem. Even given something as simple as a "SIP proxy", we have three fundamentally different modes of operation, and one of those modes has two sub-cases that require different thinking. In the first fundamental mode, the destination of the request is not changed by the proxy. The proxy gets the request, looks at it, and makes a best guess as to where the request should be sent so as to get the request closer to the destination encoded in that request. This is roughly analogous to IP routing, where the router does not change any of the addresses encoded in the packet. I call this fundamental mode "request routing". In the second fundamental mode, the proxy alters the target of the request. Under RFC 3261 as-is, this means that the request-URI is changed by the action of the proxy. In general, I call this fundamental mode "request retargeting", except that our vocabulary isn't completely consistent here. Incidentally, while the first fundamental mode is roughly analogous to IP level routing, this second fundamental mode is more similar to IP-level network address translation. Yes, we've re-invented NAT. For the purpose of future clarity, I propose we start calling this fundamental mode "request translation". There are two sub-cases of the second fundamental mode -- that is, two kinds of request translation. In the first sub-case, the proxy transforms the request-URI in a way that preserves the identity of the target. That is, the request is still going to the same distinct entity, it's just using a different request URI to get there. This is what happens when a "home proxy" does what I have in the past called "contact routing" and the original request URI is transformed from an AOR into a contact URI registered against that AOR. The important thing here is that it is reasonable for the message sender to expect the message recipient to be able to authenticate using the identities expressed in the To: header field, which is in general the same as the identity expressed in the original Request URI -- that is, as the AOR. So for example: sip:Bob@example.com registers from sip:Bob@192.168.1.1. Alice calls sip:Bob@example.com. Bob's proxy transforms this to sip:Bob@192.168.1.1. Bob gets the request, extracts the To" header field, and could reasonably insert an Identity header into the response claiming to be "sip:Bob@example.com". As I said, I've previously called this first sub-case "contact routing". We probably shouldn't, since properly it is a translation (the request URI changes), not routing. I suggest that we call this "translation with preservation of target identity" until somebody comes up with a catchier name. The most common example of translation with preservation of identity is probably the "home proxy" applying a Contact:, which we might call "contact translation". Perhaps we could use "rerouting" as a short name, and use "contact rerouting" for the thing that a home proxy does. In the second sub-case of the second fundamental mode, the proxy transforms the request URI in a way that does NOT preserve the identity of the target. That is, the request is going to a distinctly different entity from that indicated by the original request URI and the To: header field. Such a case arises if Bob forwards his calls to Charlie. Alice sends a request to "sip:Bob@example.com" and gets back a response can only be authenticated as being from "sip:Charlie@example.com". It is this second case that gives rise to the unanticipated response problem and has lead people to propose that all retargeting be replaced with redirection. We might call this sub-case "translation without preservation of target identity". We've often called this sub-case "retargeting" in the past. We also have a third fundamental mode, "redirection". In this mode, the proxy sends a response that encodes a new target for subsequent requests. The identity of this new target is independent from the identity of the original target -- it may or may not be the same, and the act of redirection says nothing about this relationship. As an example, Alice calls sip:Bob@example.com. The proxy at example.com sends Alice a response redirecting her to "sip:carol@example.com". Alice then calls "sip:carol@example.com". So to recap, we have three basic proxy operations in RFC 3261: 1) Request routing, which preserves the request URI. 2) Request rerouting, which changes the request URI but preserves the identity of the request's target. 3) Request retargeting, which changes the request URI and changes the identity of the request's target. We also have a related operation: 4) Request redirection, which informs an upstream node about a new identity to target instead of the original. As a further layer of complexity. note that these proxy operations can be stacked. That is, we might, in the process of dealing with one request, see multiple applications of the first three, followed by an application of the fourth. Leaving the unanticipated response problem aside, we have two fundamental problems with both rerouting and retargeting. The various Called-Party-ID, Target, UA-Loose-Route,and other such mechanisms are attempting to solve these problems. History-Info provides a related set of solution that also encompasses request redirection. Problem 1: Expressing the identity that was originally the target of the request. Problem 2: Delivering any end-to-end parameters that might have been encoded in the original request URI. Note that this is complicated by the possibility of end-to-middle parameters that need to be stripped by a mid-path node. We also have a related problem that, AFAIK, neither CPID, nor Target nor UA-Loose-Route attempt to solve, but that History-Info does attempt, which is: Problem 3: Expressing what operations have occurred, and WHY they have occurred, in such a way that the target, mid-path boxes, and/or the requester can do something useful with this knowledge. I've always held that this last problem is infinitely complex and that we should not try to solve it in the general case, which explains my reluctance to attack the History-Info problem (or indeed the old Diversion header, which also tickled part of this problem space). Building applications that require Ultimate Understanding seems to me to be a Bad Idea. Much as the invention of time travel will have made the concept of future-perfect tense untenable (the future will have been found not to have been perfect after all), so too is the concept of Ultimate Understanding untenable -- if you know everything, you can't possibly understand it since understanding requires knowledge outside the subject being considered, and if you understand everything you know, you'll understand you don't know everything. And that sums up the way I currently feel about the whole US-Loose-Route/CPID/Target discussion. Conclusion: New proposed vocabulary for proxy operations: request routing, rerouting, retargeting, and redirection. Call for clarity on exactly which problems we're solving with UA- Loose-Routing, target, CPID, etc. Proposed: target identity, end-to- end parameters. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 14:35:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaWT-0001TO-6f; Thu, 17 Jan 2008 14:35:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFaWQ-0001Rl-HQ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 14:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaWQ-0001RZ-78 for sip@ietf.org; Thu, 17 Jan 2008 14:35:30 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFaWO-0004DG-4q for sip@ietf.org; Thu, 17 Jan 2008 14:35:30 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m0HJZRcE012915; Thu, 17 Jan 2008 13:35:27 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 13:35:27 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 20:35:24 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Date: Thu, 17 Jan 2008 20:35:23 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001B490C0@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-index: AchZPVWoi0mzshahRDuimd0AEiSUwgAAlKKQ References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl><"0D5F89FAC29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen!s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net>A<0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , "IETF SIP List" X-OriginalArrivalTime: 17 Jan 2008 19:35:24.0765 (UTC) FILETIME=[1B1BE0D0:01C85940] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So out of interest which group would you slot the subdomain to domain translation in, e.g. drage@swindon.alcatel-lucent.com to drage@alcatel-lucent.com=20 And vice versa. And I agree, we do need some vocabulary in this area. There was a definition of some terms at a higher level in=20 http://tools.ietf.org/id/draft-rosenberg-rai-phone-names-numbers-00.txt Which we may want to reuse as well. Regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, January 17, 2008 7:13 PM > To: IETF SIP List > Subject: [Sip] Vocabulary and problem statement for=20 > Request-URI, retargeting,and SIP routing (long, but read it!) >=20 >=20 > The ongoing discussion around parameter passing mechanisms is=20 > getting wrapped up in some concepts that we really haven't=20 > yet described well enough to be communicating clearly. This=20 > message is an attempt to develop a better understanding of=20 > the basic problem. >=20 > Even given something as simple as a "SIP proxy", we have=20 > three fundamentally different modes of operation, and one of=20 > those modes has two sub-cases that require different thinking. >=20 > In the first fundamental mode, the destination of the request=20 > is not changed by the proxy. The proxy gets the request,=20 > looks at it, and makes a best guess as to where the request=20 > should be sent so as to get the request closer to the=20 > destination encoded in that request. =20 > This is roughly analogous to IP routing, where the router=20 > does not change any of the addresses encoded in the packet. I=20 > call this fundamental mode "request routing". >=20 > In the second fundamental mode, the proxy alters the target=20 > of the request. Under RFC 3261 as-is, this means that the=20 > request-URI is changed by the action of the proxy. In=20 > general, I call this fundamental mode "request retargeting",=20 > except that our vocabulary isn't completely consistent here.=20 > Incidentally, while the first fundamental mode is roughly=20 > analogous to IP level routing, this second fundamental mode=20 > is more similar to IP-level network address translation. Yes,=20 > we've re-invented NAT. For the purpose of future clarity, I=20 > propose we start calling this fundamental mode "request translation". >=20 > There are two sub-cases of the second fundamental mode --=20 > that is, two kinds of request translation. >=20 > In the first sub-case, the proxy transforms the request-URI=20 > in a way that preserves the identity of the target. That is,=20 > the request is still going to the same distinct entity, it's=20 > just using a different request URI to get there. This is what=20 > happens when a "home proxy" =20 > does what I have in the past called "contact routing" and the=20 > original request URI is transformed from an AOR into a=20 > contact URI registered against that AOR. The important thing=20 > here is that it is reasonable for the message sender to=20 > expect the message recipient to be able to authenticate using=20 > the identities expressed in the To: =20 > header field, which is in general the same as the identity=20 > expressed in the original Request URI -- that is, as the AOR.=20 > So for example: =20 > sip:Bob@example.com registers from sip:Bob@192.168.1.1. Alice=20 > calls sip:Bob@example.com. Bob's proxy transforms this to=20 > sip:Bob@192.168.1.1. Bob gets the request, extracts the To"=20 > header field, and could reasonably insert an Identity header=20 > into the response claiming to be "sip:Bob@example.com". >=20 > As I said, I've previously called this first sub-case=20 > "contact routing". We probably shouldn't, since properly it=20 > is a translation (the request URI changes), not routing. I=20 > suggest that we call this "translation with preservation of=20 > target identity" until somebody comes up with a catchier=20 > name. The most common example of translation with=20 > preservation of identity is probably the "home proxy"=20 > applying a Contact:, which we might call "contact=20 > translation". Perhaps we could use "rerouting" as a short=20 > name, and use "contact rerouting" for the thing that a home=20 > proxy does. >=20 > In the second sub-case of the second fundamental mode, the=20 > proxy transforms the request URI in a way that does NOT=20 > preserve the identity of the target. That is, the request is=20 > going to a distinctly different entity from that indicated by=20 > the original request URI and the To: header field. Such a=20 > case arises if Bob forwards his calls to Charlie. Alice sends=20 > a request to "sip:Bob@example.com" and gets back a response=20 > can only be authenticated as being from=20 > "sip:Charlie@example.com". It is this second case that gives=20 > rise to the unanticipated response problem and has lead=20 > people to propose that all retargeting be replaced with=20 > redirection. We might call this sub-case "translation without=20 > preservation of target identity". We've often called this=20 > sub-case "retargeting" in the past. >=20 > We also have a third fundamental mode, "redirection". In this=20 > mode, the proxy sends a response that encodes a new target=20 > for subsequent requests. The identity of this new target is=20 > independent from the identity of the original target -- it=20 > may or may not be the same, and the act of redirection says=20 > nothing about this relationship. As an example, Alice calls=20 > sip:Bob@example.com. The proxy at example.com sends Alice a=20 > response redirecting her to "sip:carol@example.com". =20 > Alice then calls "sip:carol@example.com". >=20 >=20 > So to recap, we have three basic proxy operations in RFC 3261: >=20 > 1) Request routing, which preserves the request URI. >=20 > 2) Request rerouting, which changes the request URI but=20 > preserves the identity of the request's target. >=20 > 3) Request retargeting, which changes the request URI and=20 > changes the identity of the request's target. >=20 > We also have a related operation: >=20 > 4) Request redirection, which informs an upstream node about=20 > a new identity to target instead of the original. >=20 >=20 > As a further layer of complexity. note that these proxy=20 > operations can be stacked. That is, we might, in the process=20 > of dealing with one request, see multiple applications of the=20 > first three, followed by an application of the fourth. >=20 >=20 > Leaving the unanticipated response problem aside, we have two=20 > fundamental problems with both rerouting and retargeting. The=20 > various Called-Party-ID, Target, UA-Loose-Route,and other=20 > such mechanisms are attempting to solve these problems.=20 > History-Info provides a related set of solution that also=20 > encompasses request redirection. >=20 > Problem 1: Expressing the identity that was originally the=20 > target of the request. >=20 > Problem 2: Delivering any end-to-end parameters that might=20 > have been encoded in the original request URI. Note that this=20 > is complicated by the possibility of end-to-middle parameters=20 > that need to be stripped by a mid-path node. >=20 > We also have a related problem that, AFAIK, neither CPID, nor=20 > Target nor UA-Loose-Route attempt to solve, but that=20 > History-Info does attempt, which is: >=20 > Problem 3: Expressing what operations have occurred, and WHY=20 > they have occurred, in such a way that the target, mid-path=20 > boxes, and/or the requester can do something useful with this=20 > knowledge. >=20 > I've always held that this last problem is infinitely complex=20 > and that we should not try to solve it in the general case,=20 > which explains my reluctance to attack the History-Info=20 > problem (or indeed the old Diversion header, which also=20 > tickled part of this problem space). Building applications=20 > that require Ultimate Understanding seems to me to be a Bad=20 > Idea. Much as the invention of time travel will have made the=20 > concept of future-perfect tense untenable (the future will=20 > have been found not to have been perfect after all), so too=20 > is the concept of Ultimate Understanding untenable -- if you=20 > know everything, you can't possibly understand it since=20 > understanding requires knowledge outside the subject being=20 > considered, and if you understand everything you know, you'll=20 > understand you don't know everything. And that sums up the=20 > way I currently feel about the whole=20 > US-Loose-Route/CPID/Target discussion. >=20 > Conclusion: >=20 > New proposed vocabulary for proxy operations: request=20 > routing, rerouting, retargeting, and redirection. >=20 > Call for clarity on exactly which problems we're solving with=20 > UA- Loose-Routing, target, CPID, etc. Proposed: target=20 > identity, end-to- end parameters. >=20 >=20 > -- > Dean Willis >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 15:24:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbGt-0003Na-Rf; Thu, 17 Jan 2008 15:23:31 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFbGs-0003NU-Db for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 15:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbGr-0003NL-MQ for sip@ietf.org; Thu, 17 Jan 2008 15:23:29 -0500 Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFbGq-0005Ag-DM for sip@ietf.org; Thu, 17 Jan 2008 15:23:29 -0500 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id eLBW1Y0071GhbT85A01X00; Thu, 17 Jan 2008 20:23:26 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA07.westchester.pa.mail.comcast.net with comcast id eLPT1Y00A0umElk3T00000; Thu, 17 Jan 2008 20:23:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=xpOt5dJgty0A:10 a=3nWAbvGqGB97OAlL77MA:9 a=3tr-h1mCgf51HtTwnycA:7 a=I_VZZgPKrPkY9x63Xdf7cfcO-xgA:4 a=gi0PWCVxevcA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m0HKNR07008784 for ; Thu, 17 Jan 2008 15:23:27 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m0HKNRNa008780; Thu, 17 Jan 2008 15:23:27 -0500 Date: Thu, 17 Jan 2008 15:23:27 -0500 Message-Id: <200801172023.m0HKNRNa008780@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Sip] Interesting problem with PRACK and resent INVITEs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was looking at a problem were were having with a phone and discovered the following interesting situation with PRACK and INVITEs that have to be resent with authentication. Consider an INVITE that gets serially forked to two destinations, the first one doesn't answer and the second one demands authentication: UAC Proxy UAS 1 UAS 2 | | | | F1 | INVITE CSeq 1 | | | |--------------->| | | F2 | | INVITE CSeq 1 | | | |-------------->| | F3 | | 180 CSeq 1 | | | | to-tag abc | | | |<--------------| | F4 | 180 CSeq 1 | | | | to-tag abc | | | |<---------------| | | F5 | PRACK CSeq 2 | | | | to-tag abc | | | |------------------------------->| | F6 | | 200 CSeq 2 | | | | to-tag abc | | |<-------------------------------| | | | | | ---------------------- delay ------------------------ | | | | F7 | | CANCEL CSq 1 | | | |-------------->| | F8 | | 200 CANCEL | | | |<--------------| | F9 | | 487 CSeq 1 | | | | to-tag abc | | | |<--------------| | F10 | | INVITE CSeq 1 | | | |------------------------------>| F11 | | | 407 CSeq 1 | | | | to-tag def | | |<------------------------------| F12 | 407 CSeq 1 | | | | to-tag def | | | |<---------------| | | F13 | INVITE CSeq 2 | | | |--------------->| | | F14 | | INVITE CSeq 2 | | | |-------------->| | F15 | | 500 CSeq 2 | | | | to-tag pqr | | | |<--------------| | F16 | 500 CSeq 2 | | | | to-tag pqr | | | |<---------------| | | | | | | Since the PRACK F5 is sent within a forked dialog, we don't think of it as using up CSeq number space in the space of out-of-dialog requests. So when it comes time to re-send the INVITE F13, it's easy to think that you can just use a CSeq one higher than the original INVITE F1. But transaction processing at UAS 1 is likely to notice that it's already seen CSeq 2 with that Call-Id. It looks like one must make sure that the re-sent INVITE has a CSeq higher than has been used in any derived dialog of the original INVITE. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 16:06:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbwT-0001E0-5n; Thu, 17 Jan 2008 16:06:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFbwR-0001Du-JQ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 16:06:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFbwR-0001Dl-9V for sip@ietf.org; Thu, 17 Jan 2008 16:06:27 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFbwQ-0006K9-ON for sip@ietf.org; Thu, 17 Jan 2008 16:06:27 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Jan 2008 16:06:26 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0HL6QW7021783; Thu, 17 Jan 2008 16:06:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0HL6Qug024564; Thu, 17 Jan 2008 21:06:26 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 16:06:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Interesting problem with PRACK and resent INVITEs Date: Thu, 17 Jan 2008 16:06:22 -0500 Message-ID: <5C5630E45267B642894988A97570D3220D2786@xmb-rtp-215.amer.cisco.com> In-Reply-To: <200801172023.m0HKNRNa008780@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs Thread-Index: AchZRw8Z4IHlyKMKSDKKZzkyuAWvCAABK/Og From: "Sanjay Sinha (sanjsinh)" To: , X-OriginalArrivalTime: 17 Jan 2008 21:06:23.0371 (UTC) FILETIME=[D0B10DB0:01C8594C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4509; t=1200603986; x=1201467986; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Interesting=20problem=20with=20 PRACK=20and=20resent=20INVITEs |Sender:=20 |To:=20,=20; bh=fqqVMdmq4jQ1VZgAukMQAwmauQu3kB31UU5iWFXrA90=; b=mb3bkjQ2hTARb4TuKW50B5FJtAI/eRPwM0KOXtNT/QmZdfFCdoVTztOlNy JD0EkmlWu/17WZSiYKuQAKqRnjP34LnmoAzcWw2ad3PJTXK9rdYIEOmk2Dmn m1XPUKvJsO; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Couple of questions. Since dialog is a combination of Call-Id + tags, and since F14 does not have a to-tag, how does UAS correlate this request to the earlier dialog. After getting 500 from UAS1, why is not sending the request to UAS2 and instead sends 500 upstream. Sanjay >-----Original Message----- >From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 >Sent: Thursday, January 17, 2008 3:23 PM >To: sip@ietf.org >Subject: [Sip] Interesting problem with PRACK and resent INVITEs > >I was looking at a problem were were having with a phone and=20 >discovered the following interesting situation with PRACK and=20 >INVITEs that have to be resent with authentication. > >Consider an INVITE that gets serially forked to two=20 >destinations, the first one doesn't answer and the second one=20 >demands authentication: > > UAC Proxy UAS 1 UAS 2 > > | | | | >F1 | INVITE CSeq 1 | | | > |--------------->| | | >F2 | | INVITE CSeq 1 | | > | |-------------->| | >F3 | | 180 CSeq 1 | | > | | to-tag abc | | > | |<--------------| | >F4 | 180 CSeq 1 | | | > | to-tag abc | | | > |<---------------| | | >F5 | PRACK CSeq 2 | | | > | to-tag abc | | | > |------------------------------->| | >F6 | | 200 CSeq 2 | | > | | to-tag abc | | > |<-------------------------------| | > | | | | > ---------------------- delay ------------------------ > | | | | >F7 | | CANCEL CSq 1 | | > | |-------------->| | >F8 | | 200 CANCEL | | > | |<--------------| | >F9 | | 487 CSeq 1 | | > | | to-tag abc | | > | |<--------------| | >F10 | | INVITE CSeq 1 | | > | |------------------------------>| >F11 | | | 407 CSeq 1 | > | | | to-tag def | > | |<------------------------------| >F12 | 407 CSeq 1 | | | > | to-tag def | | | > |<---------------| | | >F13 | INVITE CSeq 2 | | | > |--------------->| | | >F14 | | INVITE CSeq 2 | | > | |-------------->| | >F15 | | 500 CSeq 2 | | > | | to-tag pqr | | > | |<--------------| | >F16 | 500 CSeq 2 | | | > | to-tag pqr | | | > |<---------------| | | > | | | | > >Since the PRACK F5 is sent within a forked dialog, we don't=20 >think of it as using up CSeq number space in the space of=20 >out-of-dialog requests. So when it comes time to re-send the=20 >INVITE F13, it's easy to think that you can just use a CSeq=20 >one higher than the original INVITE F1. But transaction=20 >processing at UAS 1 is likely to notice that it's already seen=20 >CSeq 2 with that Call-Id. It looks like one must make sure=20 >that the re-sent INVITE has a CSeq higher than has been used=20 >in any derived dialog of the original INVITE. > >Dale > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 16:11:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc19-0004ps-Og; Thu, 17 Jan 2008 16:11:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFc17-0004pn-Mv for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 16:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc17-0004pf-D6 for sip@ietf.org; Thu, 17 Jan 2008 16:11:17 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFc17-0006QA-1j for sip@ietf.org; Thu, 17 Jan 2008 16:11:17 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 17 Jan 2008 16:11:12 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 17 Jan 2008 16:11:12 -0500 From: Hadriel Kaplan To: Dean Willis , IETF SIP List Date: Thu, 17 Jan 2008 16:08:48 -0500 Subject: RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAABVpIA Message-ID: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 17, 2008 2:13 PM > To: IETF SIP List > Subject: [Sip] Vocabulary and problem statement for Request-URI, > retargeting, and SIP routing (long, but read it!) > > So to recap, we have three basic proxy operations in RFC 3261: > > 1) Request routing, which preserves the request URI. > > 2) Request rerouting, which changes the request URI but preserves the > identity of the request's target. > > 3) Request retargeting, which changes the request URI and changes the > identity of the request's target. > > We also have a related operation: > > 4) Request redirection, which informs an upstream node about a new > identity to target instead of the original. This is described from the aspect of the downstream node sending the 3xx, r= ight? Vs. what it is for the upstream node recursing on the 3xx? (which ha= s no idea if it's performing (2) or (3) when this occurs, but I guess could= be added to the 3xx contact as a param such as described in JR's draft) So if a proxy is doing "redirection" it is sending a 3xx, whereas the upstr= eam proxy or UAC getting that 3xx is not doing redirection, but in fact "re= cursing". > Conclusion: > > New proposed vocabulary for proxy operations: request routing, > rerouting, retargeting, and redirection. Sure. Except I'm with Joel in that I don't know how a system knows when it= 's doing rerouting vs. retargeting in all cases, even if we stick to the 44= 74-type litmus test. And unfortunately a lot of systems in the path have u= ser-configured rules for what they do with the req-uri. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 16:12:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc2O-0005N0-Ds; Thu, 17 Jan 2008 16:12:36 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFc2M-0005Mq-Jw for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 16:12:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc2M-0005Mi-91 for sip@ietf.org; Thu, 17 Jan 2008 16:12:34 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFc2L-0005lr-TF for sip@ietf.org; Thu, 17 Jan 2008 16:12:34 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 17 Jan 2008 16:12:30 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 17 Jan 2008 16:12:29 -0500 From: Hadriel Kaplan To: Dean Willis , IETF SIP List Date: Thu, 17 Jan 2008 16:10:05 -0500 Subject: RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvg Message-ID: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 17, 2008 2:13 PM > > Call for clarity on exactly which problems we're solving with UA- > Loose-Routing, target, CPID, etc. Proposed: target identity, end-to- > end parameters. Not exactly. I believe the idea in the UALR draft is to get the target ide= ntity/params created by the nearest re-targeting event relative to the UAS,= where those created by the UAC is the default such event (and thus the log= ical "farthest"). In other words, what you say is true, except if the requ= est got retargeted, the identity and params will be those of the new target= , and thus not end-to-end and not always what the UAC sent. Right? For example, given the following, where "RTRG" means Re-Targeting, "RRT" me= ans Re-Routing, "RT" means Routing, and the single letters represent connec= tions: RRT +---+ |R1 | B /+---+\ C RT / \ RT +---+/ \+---+ |P1 | |P1 | A /+---+ +---+\ D / \ +---+/ \+---+ |UAC| |UAS| +---+ +---+ UA-Loose-routing wants the req-uri seen on connection "A" I think. To header gives you A. PCPID gives you B. Hist-Info gives you A,B,C. But in the re-targeting scenario such as: RTRG RRT +---+ +---+ |R1 | |R2 | B /+---+\ C E /+---+\ F RT / \ RT RT / \ RT +---+/ \+---+ D +---+/ \+---+ |P1 | |P2 +---+P3 | |P4 | A /+---+ +---+ +---+ +---+\ G / \ +---+/ \+---+ |UAC| |UAS| +---+ +---+ UA-Loose-routing wants the req-uri seen on connection "C" I think. To header gives you A. PCPID gives you E. Hist-Info gives you A,B,C,D,E,F. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 17:33:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFdIV-0007PK-DX; Thu, 17 Jan 2008 17:33:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFdIT-0007PF-Tb for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 17:33:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFdIT-0007P6-Jg for sip@ietf.org; Thu, 17 Jan 2008 17:33:17 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFdIT-00084R-BC for sip@ietf.org; Thu, 17 Jan 2008 17:33:17 -0500 Received: by an-out-0708.google.com with SMTP id d11so197737and.122 for ; Thu, 17 Jan 2008 14:33:17 -0800 (PST) Received: by 10.100.112.6 with SMTP id k6mr5439669anc.110.1200609196049; Thu, 17 Jan 2008 14:33:16 -0800 (PST) Received: by 10.100.92.16 with HTTP; Thu, 17 Jan 2008 14:33:16 -0800 (PST) Message-ID: <167dfb9b0801171433v1ec8789cwcf64e8315c95590e@mail.gmail.com> Date: Thu, 17 Jan 2008 22:33:16 +0000 From: "Theo Zourzouvillys" To: Dale.Worley@comcast.net Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs In-Reply-To: <200801172023.m0HKNRNa008780@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 17, 2008 8:23 PM, wrote: > Since the PRACK F5 is sent within a forked dialog, we don't think of > it as using up CSeq number space in the space of out-of-dialog > requests. So when it comes time to re-send the INVITE F13, it's easy > to think that you can just use a CSeq one higher than the original > INVITE F1. But transaction processing at UAS 1 is likely to notice > that it's already seen CSeq 2 with that Call-Id. It looks like one > must make sure that the re-sent INVITE has a CSeq higher than has been Dale, Surely there is no dialog for the INVITE in F14 to be interpreted in between UAC and UAS1 when it arrives as UAS1, as the previous 487 (F9) would have terminated the dialog? ~ Theo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 18:26:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFe7i-0006Zq-OR; Thu, 17 Jan 2008 18:26:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFe7g-0006Zf-VZ for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 18:26:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFe7g-0006ZX-Ju for sip@ietf.org; Thu, 17 Jan 2008 18:26:12 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFe7g-0000ZH-80 for sip@ietf.org; Thu, 17 Jan 2008 18:26:12 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0HNQ8Wu025703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2008 17:26:10 -0600 Message-ID: <478FE5D7.7010707@softarmor.com> Date: Thu, 17 Jan 2008 17:33:43 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > >> We also have a related operation: >> >> 4) Request redirection, which informs an upstream node about a new >> identity to target instead of the original. > > > This is described from the aspect of the downstream node sending the > 3xx, right? Vs. what it is for the upstream node recursing on the > 3xx? (which has no idea if it's performing (2) or (3) when this > occurs, but I guess could be added to the 3xx contact as a param such > as described in JR's draft) right. > So if a proxy is doing "redirection" it is sending a 3xx, Right. > whereas the > upstream proxy or UAC getting that 3xx is not doing redirection, but > in fact "recursing". > The upstream node is just generating a new request. It really doesn't know where that request is going, except that the new request URI was obtained during an attempt to reach the old one. We'd actually have more information from a REFER request. We've already seen all sorts of hideous problems related to an upstream proxy recursing on a 3xx. My take is that we should never do this in a proxy. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 18:37:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFeIs-0003DK-Cm; Thu, 17 Jan 2008 18:37:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFeIq-0003Ch-Vg for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 18:37:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFeIq-0003CU-KK for sip@ietf.org; Thu, 17 Jan 2008 18:37:44 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFeIq-0000o0-3m for sip@ietf.org; Thu, 17 Jan 2008 18:37:44 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0HNbeBU025767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2008 17:37:41 -0600 Message-ID: <478FE88B.30501@softarmor.com> Date: Thu, 17 Jan 2008 17:45:15 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: Thursday, January 17, 2008 2:13 PM >> >>Call for clarity on exactly which problems we're solving with UA- >>Loose-Routing, target, CPID, etc. Proposed: target identity, end-to- >>end parameters. > > > Not exactly. I believe the idea in the UALR draft is to get the > target identity/params created by the nearest re-targeting event > relative to the UAS, where those created by the UAC is the default > such event (and thus the logical "farthest"). In other words, what > you say is true, except if the request got retargeted, the identity > and params will be those of the new target, and thus not end-to-end > and not always what the UAC sent. Right? AFAIK, the original goal of UALR was to get parameters to applications. The last time I thought I understood the draft, these were preserved back somewhere on teh route stack so that the application could get them. The other thing UALR does, and this is kind of neat, is allow different sets of parameters to be stuffed in at different places, and for the UAS to be able to differentiate where those parameters were inserted (at least a little bit -- "original", "middle", and "last hop" being easy to parse.). > > For example, given the following, where "RTRG" means Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and the single letters represent connections: > > RRT > +---+ > |R1 | > B /+---+\ C > RT / \ RT > +---+/ \+---+ > |P1 | |P1 | > A /+---+ +---+\ D > / \ > +---+/ \+---+ > |UAC| |UAS| > +---+ +---+ > > UA-Loose-routing wants the req-uri seen on connection "A" I think. I think so too. > To header gives you A. > PCPID gives you B. > Hist-Info gives you A,B,C. and D is directly visible to UAS, should RT have inserted any. > > But in the re-targeting scenario such as: > RTRG RRT > +---+ +---+ > |R1 | |R2 | > B /+---+\ C E /+---+\ F > RT / \ RT RT / \ RT > +---+/ \+---+ D +---+/ \+---+ > |P1 | |P2 +---+P3 | |P4 | > A /+---+ +---+ +---+ +---+\ G > / \ > +---+/ \+---+ > |UAC| |UAS| > +---+ +---+ > > UA-Loose-routing wants the req-uri seen on connection "C" I think. > To header gives you A. > PCPID gives you E. > Hist-Info gives you A,B,C,D,E,F. As I thought I understood it, UALR gives us the stack of A and C. But I may well not understand. However, this does illustrate that there's another axis of proxy operations that can be happening. In addition to affecting the route, the target, and the identity of the target, proxies may also affect parameters. But "repararametering" is such an ugly word. And it's an ugly concept, when you think about the consequences. I'm tempted to think of all reparametering as retargeting. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 18:40:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFeLo-0001iF-Dv; Thu, 17 Jan 2008 18:40:48 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFeLm-0001i5-MA for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 18:40:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFeLm-0001hw-As for sip@ietf.org; Thu, 17 Jan 2008 18:40:46 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFeLl-0000s3-VH for sip@ietf.org; Thu, 17 Jan 2008 18:40:46 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Jan 2008 18:40:46 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0HNejkn002882; Thu, 17 Jan 2008 18:40:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0HNeaua027362; Thu, 17 Jan 2008 23:40:41 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 18:40:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Date: Thu, 17 Jan 2008 18:40:35 -0500 Message-ID: <5C5630E45267B642894988A97570D3220D2841@xmb-rtp-215.amer.cisco.com> In-Reply-To: <478FE5D7.7010707@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Index: AchZYH4EWVmzcgsbStWWTRQJKTwF/gAAWJsQ From: "Sanjay Sinha (sanjsinh)" To: "Dean Willis" , "Hadriel Kaplan" X-OriginalArrivalTime: 17 Jan 2008 23:40:36.0123 (UTC) FILETIME=[5BC2F6B0:01C85962] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2087; t=1200613245; x=1201477245; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20=09Vocabulary=20and=20problem=2 0statement=20for=20Request-URI,retargeting,=20and=20SIP=20ro uting=20(long,=20but=20read=20it!) |Sender:=20 |To:=20=22Dean=20Willis=22=20,=0 A=20=20=20=20=20=20=20=20=22Hadriel=20Kaplan=22=20; bh=ys5ezeF5sYQTTSVAD/rX5TE5VEPeC3nlFFMTiob9I8w=; b=c7fjQD6+myUdoYkRU+r1uCR3x8Xsu4C2/GqzbnsCuG7gMiJysT9KQ6ygVb LYbD8zWLedX3+NWOZGAm0T9iamP6ftX4Vqr6/NzQYa/VrNJ5FxFc3hX9rlqO 3h6Sq5BIqP; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline ... >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: Thursday, January 17, 2008 6:34 PM >To: Hadriel Kaplan >Cc: IETF SIP List >Subject: Re: [Sip] Vocabulary and problem statement for=20 >Request-URI,retargeting, and SIP routing (long, but read it!) > >Hadriel Kaplan wrote: >>=20 >>> We also have a related operation: >>>=20 >>> 4) Request redirection, which informs an upstream node about a new=20 >>> identity to target instead of the original. >>=20 >>=20 >> This is described from the aspect of the downstream node sending the=20 >> 3xx, right? Vs. what it is for the upstream node recursing on the=20 >> 3xx? (which has no idea if it's performing (2) or (3) when this=20 >> occurs, but I guess could be added to the 3xx contact as a=20 >param such=20 >> as described in JR's draft) > >right. > >> So if a proxy is doing "redirection" it is sending a 3xx, > >Right. > >> whereas the >> upstream proxy or UAC getting that 3xx is not doing redirection, but=20 >> in fact "recursing". >>=20 > >The upstream node is just generating a new request. It really=20 >doesn't know where that request is going, except that the new=20 >request URI was obtained during an attempt to reach the old=20 >one.=20 Not sure what you mean here? The next request-uri is taken from Contact of the redirect response. So it knows where the request is going. > We'd actually have more information from a REFER request. How is the Refer-To header different that Contacts in redirect response? Sanjay > >We've already seen all sorts of hideous problems related to an=20 >upstream proxy recursing on a 3xx. My take is that we should=20 >never do this in a proxy. > >-- >Dean > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 20:20:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFfuE-0004Yc-Uh; Thu, 17 Jan 2008 20:20:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFfuD-0004YS-AU for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 20:20:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFfuC-0004YK-Sg for sip@ietf.org; Thu, 17 Jan 2008 20:20:24 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFfuC-0002pd-Aw for sip@ietf.org; Thu, 17 Jan 2008 20:20:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jan 2008 20:20:24 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0I1KOCV015538; Thu, 17 Jan 2008 20:20:24 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0I1KOuc029093; Fri, 18 Jan 2008 01:20:27 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 20:20:21 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 20:20:21 -0500 Message-ID: <478FFED9.7080307@cisco.com> Date: Thu, 17 Jan 2008 20:20:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> In-Reply-To: <200801172023.m0HKNRNa008780@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 01:20:21.0657 (UTC) FILETIME=[4B6AF890:01C85970] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4675; t=1200619224; x=1201483224; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Interesting=20problem=20with=20 PRACK=20and=20resent=20INVITEs |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=N8LsM5+OUxFLbpnAQMRABawj83w1lEs7E0VERrctoHU=; b=R4vBEpXQ4oe7ZKWcSaLm4mWNNwJjZdix/OvVBX97MqcL9WSGbDYh+5WfFK hgcRqcm07ZGKy0Rq3zBs65+74QQ4cavIkrgIJC/Hd/CSFD3fNerJ6pi8Bmks 5AsXAdwBgX; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Interesting. But I'm not certain I buy it. CSeqs only make sense within a dialog. F13 doesn't contain the To-tag abc, so it ought not be expected to use a valid CSeq for that dialog. A different issue here is that that F13 ought not go to UAS1 at all. But we treat it as a new transaction, and don't expect the proxy to maintain any history across transactions, so we don't have a way to prevent that. There ought to be something in F11 that causes the request to go only to (in this case) UA2. (In general to whichever node generated the challenge, which might have been a proxy rather than a UA.) Paul Dale.Worley@comcast.net wrote: > I was looking at a problem were were having with a phone and > discovered the following interesting situation with PRACK and INVITEs > that have to be resent with authentication. > > Consider an INVITE that gets serially forked to two destinations, the > first one doesn't answer and the second one demands authentication: > > UAC Proxy UAS 1 UAS 2 > > | | | | > F1 | INVITE CSeq 1 | | | > |--------------->| | | > F2 | | INVITE CSeq 1 | | > | |-------------->| | > F3 | | 180 CSeq 1 | | > | | to-tag abc | | > | |<--------------| | > F4 | 180 CSeq 1 | | | > | to-tag abc | | | > |<---------------| | | > F5 | PRACK CSeq 2 | | | > | to-tag abc | | | > |------------------------------->| | > F6 | | 200 CSeq 2 | | > | | to-tag abc | | > |<-------------------------------| | > | | | | > ---------------------- delay ------------------------ > | | | | > F7 | | CANCEL CSq 1 | | > | |-------------->| | > F8 | | 200 CANCEL | | > | |<--------------| | > F9 | | 487 CSeq 1 | | > | | to-tag abc | | > | |<--------------| | > F10 | | INVITE CSeq 1 | | > | |------------------------------>| > F11 | | | 407 CSeq 1 | > | | | to-tag def | > | |<------------------------------| > F12 | 407 CSeq 1 | | | > | to-tag def | | | > |<---------------| | | > F13 | INVITE CSeq 2 | | | > |--------------->| | | > F14 | | INVITE CSeq 2 | | > | |-------------->| | > F15 | | 500 CSeq 2 | | > | | to-tag pqr | | > | |<--------------| | > F16 | 500 CSeq 2 | | | > | to-tag pqr | | | > |<---------------| | | > | | | | > > Since the PRACK F5 is sent within a forked dialog, we don't think of > it as using up CSeq number space in the space of out-of-dialog > requests. So when it comes time to re-send the INVITE F13, it's easy > to think that you can just use a CSeq one higher than the original > INVITE F1. But transaction processing at UAS 1 is likely to notice > that it's already seen CSeq 2 with that Call-Id. It looks like one > must make sure that the re-sent INVITE has a CSeq higher than has been > used in any derived dialog of the original INVITE. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 17 23:34:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFivH-0001s7-L3; Thu, 17 Jan 2008 23:33:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFivF-0001s2-U6 for sip-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 23:33:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFivF-0001ru-It for sip@ietf.org; Thu, 17 Jan 2008 23:33:41 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFivD-0006Zw-6a for sip@ietf.org; Thu, 17 Jan 2008 23:33:39 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 17 Jan 2008 23:33:34 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 17 Jan 2008 23:33:32 -0500 From: Hadriel Kaplan To: Dean Willis Date: Thu, 17 Jan 2008 23:30:44 -0500 Subject: RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) Thread-Index: AchZYfL1QvCIyH0OTa25KVenIalpMwAJtXyA Message-ID: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <478FE88B.30501@softarmor.com> In-Reply-To: <478FE88B.30501@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 17, 2008 6:45 PM > > AFAIK, the original goal of UALR was to get parameters to applications. > The last time I thought I understood the draft, these were preserved > back somewhere on teh route stack so that the application could get them. That may have been the intent, but as I read draft-rosenberg-sip-ua-loose-r= oute-01.txt, it doesn't do that if a retarget occurs. In a retargeting cas= e the req-uri is replaced with the new target. In the rerouting case, the = req-uri is left alone, and the newly resolved destination URI (for lack of = a better term) would be pushed as a Route header. It does, though, say the previous req-uri would be pushed into the History-= Info header. It would have been before this draft too, if people implement= ed it, except with this new draft ONLY retarget cases would push a History-= Info. So I guess in that sense you're right, the pre-retargeting data coul= d be there in that. > > > > But in the re-targeting scenario such as: > > RTRG RRT > > +---+ +---+ > > |R1 | |R2 | > > B /+---+\ C E /+---+\ F > > RT / \ RT RT / \ RT > > +---+/ \+---+ D +---+/ \+---+ > > |P1 | |P2 +---+P3 | |P4 | > > A /+---+ +---+ +---+ +---+\ G > > / \ > > +---+/ \+---+ > > |UAC| |UAS| > > +---+ +---+ > > > > UA-Loose-routing wants the req-uri seen on connection "C" I think. > > To header gives you A. > > PCPID gives you E. > > Hist-Info gives you A,B,C,D,E,F. > > As I thought I understood it, UALR gives us the stack of A and C. If R1 and R2 did UALR, the UAS would get the req-uri from C, a History-Info= with B, and there'd be a Route header with UAS' contact. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 00:04:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjOu-0004zu-Fi; Fri, 18 Jan 2008 00:04:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFjOt-0004zf-B1 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:04:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjOs-0004zU-W8 for sip@ietf.org; Fri, 18 Jan 2008 00:04:19 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFjOs-000785-JW for sip@ietf.org; Fri, 18 Jan 2008 00:04:18 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 00:04:14 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Jan 2008 00:04:11 -0500 From: Hadriel Kaplan To: Jonathan Rosenberg Date: Fri, 18 Jan 2008 00:01:23 -0500 Thread-Topic: Questions on draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: AchZjyv6dvLVMVd5SbqtJg2n4wglvQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List Subject: [Sip] Questions on draft-rosenberg-sip-ua-loose-route-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If I read the draft correctly, the proposed solution is that rerouting acti= on leaves the req-uri alone, and pushes a Route for the resolved target's U= RI (contact/whatever). Whereas a retargeting action replaces the req-uri w= ith the new target, and possibly pushes the previous req-uri into History-I= nfo. The draft proposes retargeting be defined as when the proxy determine= s the new target could not claim the previous req-uri as its Identity. In = other words, if the new target were to originate a request using the previo= us req-uri as its From addr-spec, would its domain sign it using rfc4474 - = if so then it's a reroute, if not then it's a retarget. Correct? The draft also describes several cases, some of which don't seem to follow = the above rules. For example, Section 5 example 3 says: 3. When a proxy receiving a request identifies a next hop server that is needed to process the request, that next hop server is a route. A next hop server is not a UA and would never be able to claim its identity. Its URI is pushed into a Route header field and the Request-URI is retained. An important use case for this are proxies that select PSTN gateways for call egress to the PSTN. Such selection would place the SIP URI of the gateway into the topmost Route header field value and retain the Request-URI. So this says a PSTN gateway could not claim the identity, yet the behavior = is still rerouting? Another example of this is in Section 2.6 for Emergency Numbers. It states= the SOS URN needs to stay in place in the req-uri all the way to the call-= taker. I'm not sure if such a call-taker could claim Identity to an SOS UR= N, and furthermore the odds are the call-taker is in another domain, which = per this draft would constitute a retargeting and change the req-uri. No? This draft should also describe what happens for service invocation, which = is a stated problem space in section 2.5. Again, a voicemail system or IVR= or App Server could not claim Identity for the req-uri, and thus it would = be a retarget per the draft's definition. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 00:17:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjbt-0007GY-Ps; Fri, 18 Jan 2008 00:17:45 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFjbq-00070O-Ml for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:17:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjbq-00070F-BK for sip@ietf.org; Fri, 18 Jan 2008 00:17:42 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFjbp-0007WF-I5 for sip@ietf.org; Fri, 18 Jan 2008 00:17:42 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6ABED209DE; Fri, 18 Jan 2008 06:17:40 +0100 (CET) X-AuditID: c1b4fb3c-a9aebbb0000007e0-00-47903674413e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 457B9203DB; Fri, 18 Jan 2008 06:17:40 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 06:17:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Interesting problem with PRACK and resent INVITEs Date: Fri, 18 Jan 2008 06:17:39 +0100 Message-ID: In-Reply-To: <478FFED9.7080307@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs Thread-Index: AchZcG4EAvEf/8+nRSe8h70Sn8MxLgAIG1GQ References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 18 Jan 2008 05:17:39.0848 (UTC) FILETIME=[720A8080:01C85991] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Interesting. But I'm not certain I buy it. CSeqs only make=20 >sense within a dialog. F13 doesn't contain the To-tag abc, so=20 >it ought not be expected to use a valid CSeq for that dialog. Correct. And, the INVITEs shall contain different From-tag values (and Call-ID values), so UAS 2 will be able to differentiate the dialogs based on those parameters. Regards, Christer >=20 >A different issue here is that that F13 ought not go to UAS1=20 >at all. But we treat it as a new transaction, and don't=20 >expect the proxy to maintain any history across transactions,=20 >so we don't have a way to prevent that. >=20 >There ought to be something in F11 that causes the request to=20 >go only to (in this case) UA2. (In general to whichever node generated=20 >the challenge, which might have been a proxy rather than a UA.) >=20 > Paul >=20 > Dale.Worley@comcast.net wrote: > > I was looking at a problem were were having with a phone and=20 > > discovered the following interesting situation with PRACK=20 > and INVITEs=20 > > that have to be resent with authentication. > >=20 > > Consider an INVITE that gets serially forked to two=20 > destinations, the=20 > > first one doesn't answer and the second one demands authentication: > >=20 > > UAC Proxy UAS 1 UAS 2 > >=20 > > | | | | > > F1 | INVITE CSeq 1 | | | > > |--------------->| | | > > F2 | | INVITE CSeq 1 | | > > | |-------------->| | > > F3 | | 180 CSeq 1 | | > > | | to-tag abc | | > > | |<--------------| | > > F4 | 180 CSeq 1 | | | > > | to-tag abc | | | > > |<---------------| | | > > F5 | PRACK CSeq 2 | | | > > | to-tag abc | | | > > |------------------------------->| | > > F6 | | 200 CSeq 2 | | > > | | to-tag abc | | > > |<-------------------------------| | > > | | | | > > ---------------------- delay ------------------------ > > | | | | > > F7 | | CANCEL CSq 1 | | > > | |-------------->| | > > F8 | | 200 CANCEL | | > > | |<--------------| | > > F9 | | 487 CSeq 1 | | > > | | to-tag abc | | > > | |<--------------| | > > F10 | | INVITE CSeq 1 | | > > | |------------------------------>| > > F11 | | | 407 CSeq 1 | > > | | | to-tag def | > > | |<------------------------------| > > F12 | 407 CSeq 1 | | | > > | to-tag def | | | > > |<---------------| | | > > F13 | INVITE CSeq 2 | | | > > |--------------->| | | > > F14 | | INVITE CSeq 2 | | > > | |-------------->| | > > F15 | | 500 CSeq 2 | | > > | | to-tag pqr | | > > | |<--------------| | > > F16 | 500 CSeq 2 | | | > > | to-tag pqr | | | > > |<---------------| | | > > | | | | > >=20 > > Since the PRACK F5 is sent within a forked dialog, we don't=20 > think of=20 > > it as using up CSeq number space in the space of out-of-dialog=20 > > requests. So when it comes time to re-send the INVITE F13,=20 > it's easy=20 > > to think that you can just use a CSeq one higher than the original=20 > > INVITE F1. But transaction processing at UAS 1 is likely to notice=20 > > that it's already seen CSeq 2 with that Call-Id. It looks like one=20 > > must make sure that the re-sent INVITE has a CSeq higher=20 > than has been=20 > > used in any derived dialog of the original INVITE. > >=20 > > Dale > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 00:34:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjrj-0008Mr-Bw; Fri, 18 Jan 2008 00:34:07 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFjrh-0008Jc-9P for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 00:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjrg-0008Ht-UV for sip@ietf.org; Fri, 18 Jan 2008 00:34:04 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFjrg-0006ff-D4 for sip@ietf.org; Fri, 18 Jan 2008 00:34:04 -0500 Received: from [206.176.144.213] (206-176-144-213.waymark.net [206.176.144.213]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0I5XtNj027388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2008 23:33:57 -0600 Message-ID: <47903A44.4070009@softarmor.com> Date: Thu, 17 Jan 2008 23:33:56 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) References: <5C5630E45267B642894988A97570D3220D2841@xmb-rtp-215.amer.cisco.com> In-Reply-To: <5C5630E45267B642894988A97570D3220D2841@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sanjay Sinha (sanjsinh) wrote: > Inline ... > > >>> whereas the >>> upstream proxy or UAC getting that 3xx is not doing redirection, but >>> in fact "recursing". >>> >>> >> The upstream node is just generating a new request. It really >> doesn't know where that request is going, except that the new >> request URI was obtained during an attempt to reach the old >> one. >> > Not sure what you mean here? The next request-uri is taken from Contact > of the redirect response. So it knows where the request is going. > It knows the URI that the request is going to. It doesn't know "who" that URI will reach, or what their relationship to the original URI is (unless perhaps "History-Info" explains it). However, this is at least enough knowledge to be able to prevent the unanticipated response problem sometimes, because we can at least check that the identity expressed in the eventual response matches that received in the 302. Assuming, of course, that the new URI doesn't go through some sort of retargeting operation that does not preserve the request identity. > >> We'd actually have more information from a REFER request. >> > How is the Refer-To header different that Contacts in redirect response? > > We're not really sure where the 3xx response came from. All we know is that it was generated somewhere along the path towards the original request-URI. REFER, however, is a request instead of a response, so we can use the various request-authentication techniques to figure out who sent it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 02:26:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlc2-0003Is-45; Fri, 18 Jan 2008 02:26:02 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFlc1-0003In-0l for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 02:26:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlc0-0003IR-Lg for sip@ietf.org; Fri, 18 Jan 2008 02:26:00 -0500 Received: from smtp6.versatel.nl ([62.58.50.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFlbz-0002WB-Ld for sip@ietf.org; Fri, 18 Jan 2008 02:26:00 -0500 Received: (qmail 18310 invoked by uid 0); 18 Jan 2008 07:27:04 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jan 2008 07:27:04 -0000 Message-ID: <4790547E.8000009@zonnet.nl> Date: Fri, 18 Jan 2008 08:25:50 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, No, see RFC3261 8.1.1.4: Note that when requests are retried after certain failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. Mid-dialog challenges should use the same from-tag + Call-ID, so although it seems allowed to start anew, IMHO it is better to keep them the same. The text could be more clear though (and should have some normative words). Regarding from tags there is no explicit text, but 22.2 says: When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request. This hints at treating the challenge response as a mid-call request (although it may have no to-tag in case of an initial INVITE) Regarding Dale's case below, this can only occur if UAS1 has a broken SIP implementation (F1, F5 and F13 are 3 independent transactions) Regards, Jeroen Christer Holmberg wrote: > Hi, > >> Interesting. But I'm not certain I buy it. CSeqs only make >> sense within a dialog. F13 doesn't contain the To-tag abc, so >> it ought not be expected to use a valid CSeq for that dialog. > > Correct. > > And, the INVITEs shall contain different From-tag values (and Call-ID > values), so UAS 2 will be able to differentiate the dialogs based on > those parameters. > > Regards, > > Christer > > > > >> A different issue here is that that F13 ought not go to UAS1 >> at all. But we treat it as a new transaction, and don't >> expect the proxy to maintain any history across transactions, >> so we don't have a way to prevent that. >> >> There ought to be something in F11 that causes the request to >> go only to (in this case) UA2. (In general to whichever node generated >> the challenge, which might have been a proxy rather than a UA.) >> >> Paul >> >> Dale.Worley@comcast.net wrote: >>> I was looking at a problem were were having with a phone and >>> discovered the following interesting situation with PRACK >> and INVITEs >>> that have to be resent with authentication. >>> >>> Consider an INVITE that gets serially forked to two >> destinations, the >>> first one doesn't answer and the second one demands authentication: >>> >>> UAC Proxy UAS 1 UAS 2 >>> >>> | | | | >>> F1 | INVITE CSeq 1 | | | >>> |--------------->| | | >>> F2 | | INVITE CSeq 1 | | >>> | |-------------->| | >>> F3 | | 180 CSeq 1 | | >>> | | to-tag abc | | >>> | |<--------------| | >>> F4 | 180 CSeq 1 | | | >>> | to-tag abc | | | >>> |<---------------| | | >>> F5 | PRACK CSeq 2 | | | >>> | to-tag abc | | | >>> |------------------------------->| | >>> F6 | | 200 CSeq 2 | | >>> | | to-tag abc | | >>> |<-------------------------------| | >>> | | | | >>> ---------------------- delay ------------------------ >>> | | | | >>> F7 | | CANCEL CSq 1 | | >>> | |-------------->| | >>> F8 | | 200 CANCEL | | >>> | |<--------------| | >>> F9 | | 487 CSeq 1 | | >>> | | to-tag abc | | >>> | |<--------------| | >>> F10 | | INVITE CSeq 1 | | >>> | |------------------------------>| >>> F11 | | | 407 CSeq 1 | >>> | | | to-tag def | >>> | |<------------------------------| >>> F12 | 407 CSeq 1 | | | >>> | to-tag def | | | >>> |<---------------| | | >>> F13 | INVITE CSeq 2 | | | >>> |--------------->| | | >>> F14 | | INVITE CSeq 2 | | >>> | |-------------->| | >>> F15 | | 500 CSeq 2 | | >>> | | to-tag pqr | | >>> | |<--------------| | >>> F16 | 500 CSeq 2 | | | >>> | to-tag pqr | | | >>> |<---------------| | | >>> | | | | >>> >>> Since the PRACK F5 is sent within a forked dialog, we don't >> think of >>> it as using up CSeq number space in the space of out-of-dialog >>> requests. So when it comes time to re-send the INVITE F13, >> it's easy >>> to think that you can just use a CSeq one higher than the original >>> INVITE F1. But transaction processing at UAS 1 is likely to notice >>> that it's already seen CSeq 2 with that Call-Id. It looks like one >>> must make sure that the re-sent INVITE has a CSeq higher >> than has been >>> used in any derived dialog of the original INVITE. >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@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@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 02:37:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlmc-0006V6-9E; Fri, 18 Jan 2008 02:36:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFlma-0006Uy-45 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 02:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlmZ-0006Uq-QN for sip@ietf.org; Fri, 18 Jan 2008 02:36:55 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFlmY-0000Sm-P4 for sip@ietf.org; Fri, 18 Jan 2008 02:36:55 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1951E20C47; Fri, 18 Jan 2008 08:36:52 +0100 (CET) X-AuditID: c1b4fb3c-ab2eebb0000007e0-1b-479057135389 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E4D6D203CF; Fri, 18 Jan 2008 08:36:51 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 08:36:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Interesting problem with PRACK and resent INVITEs Date: Fri, 18 Jan 2008 08:36:50 +0100 Message-ID: In-Reply-To: <4790547E.8000009@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs Thread-Index: AchZo1917ZPPwjE1QjaDgKmcxOZ04AAACiwg References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> <4790547E.8000009@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 18 Jan 2008 07:36:51.0769 (UTC) FILETIME=[E42C8290:01C859A4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >No, see RFC3261 8.1.1.4: >=20 >Note that when requests are retried after certain failure=20 >responses that solicit an amendment to a request (for >example, a challenge for authentication), these retried=20 >requests are not considered new requests, and therefore do not need new Call-ID >header fields; see Section 8.1.3.5. Correct. >Mid-dialog challenges should use the same from-tag + Call-ID,=20 >so although it seems allowed to start anew, IMHO it is better=20 >to keep them the same.=20 >The text could be more clear though (and should have some=20 >normative words). > >=20 >Regarding from tags there is no explicit text, but 22.2 says: >=20 >When a UAC resubmits a request with its credentials after receiving a >401 (Unauthorized) or 407 (Proxy Authentication Required) response, >it MUST increment the CSeq header field value as it would normally >when sending an updated request. So, I guess that means that the second INVITE in Dale's example should have Cseq =3D> 3. =20 >This hints at treating the challenge response as a mid-call=20 >request (although it may have no to-tag in case of an initial INVITE) Personally I think that EVERY new initial INVITE should be update the Call-ID and/or From-tag, no matter what triggered it. But, I guess there is a good reason behind the current text... Regards, Christer > Christer Holmberg wrote: > > Hi, > > > >> Interesting. But I'm not certain I buy it. CSeqs only make sense=20 > >> within a dialog. F13 doesn't contain the To-tag abc, so it=20 > ought not=20 > >> be expected to use a valid CSeq for that dialog. > > > > Correct. > > > > And, the INVITEs shall contain different From-tag values=20 > (and Call-ID=20 > > values), so UAS 2 will be able to differentiate the dialogs=20 > based on=20 > > those parameters. > > > > Regards, > > > > Christer > > > > > > > > > >> A different issue here is that that F13 ought not go to=20 > UAS1 at all.=20 > >> But we treat it as a new transaction, and don't expect the=20 > proxy to=20 > >> maintain any history across transactions, so we don't have=20 > a way to=20 > >> prevent that. > >> > >> There ought to be something in F11 that causes the request=20 > to go only=20 > >> to (in this case) UA2. (In general to whichever node generated the=20 > >> challenge, which might have been a proxy rather than a UA.) > >> > >> Paul > >> > >> Dale.Worley@comcast.net wrote: > >>> I was looking at a problem were were having with a phone and=20 > >>> discovered the following interesting situation with PRACK > >> and INVITEs > >>> that have to be resent with authentication. > >>> > >>> Consider an INVITE that gets serially forked to two > >> destinations, the > >>> first one doesn't answer and the second one demands=20 > authentication: > >>> > >>> UAC Proxy UAS 1 UAS 2 > >>> > >>> | | | | > >>> F1 | INVITE CSeq 1 | | | > >>> |--------------->| | | > >>> F2 | | INVITE CSeq 1 | | > >>> | |-------------->| | > >>> F3 | | 180 CSeq 1 | | > >>> | | to-tag abc | | > >>> | |<--------------| | > >>> F4 | 180 CSeq 1 | | | > >>> | to-tag abc | | | > >>> |<---------------| | | > >>> F5 | PRACK CSeq 2 | | | > >>> | to-tag abc | | | > >>> |------------------------------->| | > >>> F6 | | 200 CSeq 2 | | > >>> | | to-tag abc | | > >>> |<-------------------------------| | > >>> | | | | > >>> ---------------------- delay ------------------------ > >>> | | | | > >>> F7 | | CANCEL CSq 1 | | > >>> | |-------------->| | > >>> F8 | | 200 CANCEL | | > >>> | |<--------------| | > >>> F9 | | 487 CSeq 1 | | > >>> | | to-tag abc | | > >>> | |<--------------| | > >>> F10 | | INVITE CSeq 1 | | > >>> | |------------------------------>| > >>> F11 | | | 407 CSeq 1 | > >>> | | | to-tag def | > >>> | |<------------------------------| > >>> F12 | 407 CSeq 1 | | | > >>> | to-tag def | | | > >>> |<---------------| | | > >>> F13 | INVITE CSeq 2 | | | > >>> |--------------->| | | > >>> F14 | | INVITE CSeq 2 | | > >>> | |-------------->| | > >>> F15 | | 500 CSeq 2 | | > >>> | | to-tag pqr | | > >>> | |<--------------| | > >>> F16 | 500 CSeq 2 | | | > >>> | to-tag pqr | | | > >>> |<---------------| | | > >>> | | | | > >>> > >>> Since the PRACK F5 is sent within a forked dialog, we don't > >> think of > >>> it as using up CSeq number space in the space of out-of-dialog=20 > >>> requests. So when it comes time to re-send the INVITE F13, > >> it's easy > >>> to think that you can just use a CSeq one higher than the=20 > original=20 > >>> INVITE F1. But transaction processing at UAS 1 is likely=20 > to notice=20 > >>> that it's already seen CSeq 2 with that Call-Id. It=20 > looks like one=20 > >>> must make sure that the re-sent INVITE has a CSeq higher > >> than has been > >>> used in any derived dialog of the original INVITE. > >>> > >>> Dale > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@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=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@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=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 02:45:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFluP-0005do-JW; Fri, 18 Jan 2008 02:45:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFluO-0005Zc-5F for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 02:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFluA-0005Vq-VY for sip@ietf.org; Fri, 18 Jan 2008 02:44:46 -0500 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFlu9-0000ZV-EC for sip@ietf.org; Fri, 18 Jan 2008 02:44:46 -0500 Received: (qmail 32164 invoked by uid 0); 18 Jan 2008 07:44:16 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jan 2008 07:44:16 -0000 Message-ID: <479058E4.2050902@zonnet.nl> Date: Fri, 18 Jan 2008 08:44:36 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Regarding > > > We also have a related operation: > > 4) Request redirection, which informs an upstream node about a new > identity to target instead of the original. > Redirection does not always imply a new identity, it could be an alternative Contact for the same identity. The thing is that we cannot easily distinguish between these, since both use the same response code (302). So it can be either rerouting or retargeting. For the problem at hand this makes no difference though, in any case the request URI is replaced. BTW what happened to the 'opaque' parameter solution that was part of a GRUU draft some versions ago? A special URI parameter that survives rerouting/retargeting would avoid introducing yet another identity header, and also detection-of-support issues. Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 02:48:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlxg-0000cE-Bn; Fri, 18 Jan 2008 02:48:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFlxe-0000PH-OY for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 02:48:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlxe-0000K9-9v for sip@ietf.org; Fri, 18 Jan 2008 02:48:22 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFlxc-0000e3-Gz for sip@ietf.org; Fri, 18 Jan 2008 02:48:22 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUT0053LXOJ2O@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Jan 2008 07:48:19 +0000 (GMT) Date: Fri, 18 Jan 2008 07:48:18 +0000 From: "Elwell, John" Subject: RE: [Sip] Vocabulary and problem statement for Request-URI,retargeting, and SIP routing (long, but read it!) In-reply-to: To: Hadriel Kaplan , Dean Willis , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI,retargeting, and SIP routing (long, but read it!) thread-index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <"0 D5F89FAC29E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, Comment at the end. John=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 17 January 2008 21:10 > To: Dean Willis; IETF SIP List > Subject: RE: [Sip] Vocabulary and problem statement for=20 > Request-URI,retargeting, and SIP routing (long, but read it!) >=20 >=20 >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, January 17, 2008 2:13 PM > > > > Call for clarity on exactly which problems we're solving with UA- > > Loose-Routing, target, CPID, etc. Proposed: target identity, end-to- > > end parameters. >=20 > Not exactly. I believe the idea in the UALR draft is to get=20 > the target identity/params created by the nearest=20 > re-targeting event relative to the UAS, where those created=20 > by the UAC is the default such event (and thus the logical=20 > "farthest"). In other words, what you say is true, except if=20 > the request got retargeted, the identity and params will be=20 > those of the new target, and thus not end-to-end and not=20 > always what the UAC sent. Right? >=20 > For example, given the following, where "RTRG" means=20 > Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and=20 > the single letters represent connections: >=20 > RRT > +---+ > |R1 | > B /+---+\ C > RT / \ RT > +---+/ \+---+ > |P1 | |P1 | > A /+---+ +---+\ D > / \ > +---+/ \+---+ > |UAC| |UAS| > +---+ +---+ >=20 > UA-Loose-routing wants the req-uri seen on connection "A" I think. > To header gives you A. > PCPID gives you B. > Hist-Info gives you A,B,C. >=20 >=20 > But in the re-targeting scenario such as: > RTRG RRT > +---+ +---+ > |R1 | |R2 | > B /+---+\ C E /+---+\ F > RT / \ RT RT / \ RT > +---+/ \+---+ D +---+/ \+---+ > |P1 | |P2 +---+P3 | |P4 | > A /+---+ +---+ +---+ +---+\ G > / \ > +---+/ \+---+ > |UAC| |UAS| > +---+ +---+ >=20 > UA-Loose-routing wants the req-uri seen on connection "C" I think. > To header gives you A. > PCPID gives you E. > Hist-Info gives you A,B,C,D,E,F. [JRE] According to Dean's definition of RT, it does not change the Request-URI (only the Route header field presumably, or maybe not even that). So C, D and E are the same. Also A and B are the same, and F and G are the same. So I think: - UA-Loose-routing gives you C/D/E - To gives you A/B - PCPID gives you C/D/E - Target gives you C/D/E - Hist-info gives you A/B, C/D/E and F/G. =20 >=20 > -hadriel >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 03:02:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFmBD-0007Pz-Gi; Fri, 18 Jan 2008 03:02:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFmBC-0007Pu-2k for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 03:02:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFmBB-0007Pk-Og for sip@ietf.org; Fri, 18 Jan 2008 03:02:21 -0500 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFmBB-0003EI-Af for sip@ietf.org; Fri, 18 Jan 2008 03:02:21 -0500 Received: (qmail 10364 invoked by uid 0); 18 Jan 2008 08:01:52 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jan 2008 08:01:52 -0000 Message-ID: <47905D04.6050509@zonnet.nl> Date: Fri, 18 Jan 2008 09:02:12 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> <4790547E.8000009@zonnet.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, >> . >> >> >> Regarding from tags there is no explicit text, but 22.2 says: >> >> When a UAC resubmits a request with its credentials after receiving a >> 401 (Unauthorized) or 407 (Proxy Authentication Required) response, >> it MUST increment the CSeq header field value as it would normally >> when sending an updated request. >> > > So, I guess that means that the second INVITE in Dale's example should > have Cseq => 3. I interpreted this as "MUST increment (relative to the INVITE being challenged)". I guess for initial INVITEs the minimal requirement is that the CSeq be different, else merged request detection (8.2.2.2) could kick in and prevent the call from succeeding. So both 2 or 3 are valid, the text is ambiguous Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 04:29:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnWQ-0007V4-8A; Fri, 18 Jan 2008 04:28:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFnWP-0007Ux-2C for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 04:28:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnWO-0007Up-Lj for sip@ietf.org; Fri, 18 Jan 2008 04:28:20 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFnWN-0005I9-DD for sip@ietf.org; Fri, 18 Jan 2008 04:28:20 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5BDA520E10; Fri, 18 Jan 2008 10:28:00 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-45-4790712038da Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40B3220DD8; Fri, 18 Jan 2008 10:28:00 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:27:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on RFC3840/3841 Date: Fri, 18 Jan 2008 10:27:59 +0100 Message-ID: In-Reply-To: <478633C4.2060209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on RFC3840/3841 Thread-Index: AchTmf6noFFXdaVITfq5Wi/PDr3BpAGGXRgA References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> <478629C1.5090404@cisco.com> <478633C4.2060209@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 18 Jan 2008 09:27:59.0797 (UTC) FILETIME=[6AA0D650:01C859B4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, =20 >RFC3840 by itself, without 2533, is *not* sufficient to=20 >understand how to do the matching. >=20 >I put an appendix in RFC 4596 that gives an algorithm without=20 >reference to 2533. I *think* it is right, but of course it is=20 >not normative. >=20 >Note that IMO none of this is intuitive or straightforward.=20 >Every time I get a detailed question on it I have to do a=20 >bunch of review before I can answer it. (But maybe that's=20 >just because I don't have enough neurons left.) And I thought SIP was supposed to be easy... One question: In chapter 6 (I guess that is what you call the annex) of 4596 you say: "The simplification is primarily because a particular feature tag may only appear once in each Contact, Accept-Contact, or Reject-Contact header." However, as seen before, a particular feature tag may appear more than once, but in different A-C headers (or ac-values within a single header). For example: Accept-Contact: *;tagQ Accept-Contact: *;tagQ And, from a matching perspective, does it really matter if the feature tags were taken from one or more A-C headers? For example: Isn't: Accept-Contact: *;tagY,tagW ...identical to: Accept-Contact: *;tagY Accept-Contact: *;tagW ...or: Accept-Contact: *;tagY, *;tagW They will all cause: (& (tagY) (tagW)) Or? Regards, Christer >=20 > Paul >=20 > Christer Holmberg wrote: > > Paul, > >=20 > > Regarding the matching, are you saying that reading RFC3840=20 > is enough=20 > > to understand how the matching is done in a "SIP=20 > environment"? Or, do=20 > > I also need to read RFC2533? > >=20 > > I have some questions on the matching, but I will come back to them=20 > > later. I still have some reading to do. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 10. tammikuuta 2008 16:21 > >> To: Mahesh Anjanappa > >> Cc: Christer Holmberg; sip@ietf.org > >> Subject: Re: [Sip] Question on RFC3840/3841 > >> > >> > >> > >> Mahesh Anjanappa wrote: > >>> Yes the ';' is a mistake. But i'm not sure if each=20 > Contact should=20 > >>> contain "alice@atlanta.com" > >> Well, it has to have a URI to be syntactically correct. > >> > >> Your problem is that you are trying to express something=20 > that cannot=20 > >> be expressed with the callee caps syntax. It only maps to=20 > a subset of=20 > >> the syntax supported by RFC 2533. > >> > >>> because the predicate that i'm trying to represent is as follows=20 > >>> meanig to say alice supports a communication which whose > >> capability is > >>> Duplex Audio + One Way Video. > >> You just can't say that. Sorry. > >> > >> A little history may help you to understand, though it won't solve=20 > >> your > >> problem: > >> > >> The initial draft for callerprefs came out a very long=20 > time ago. (The=20 > >> earliest draft I have is -03 which came out in november of=20 > 2000.) It=20 > >> set the basic syntax and the initial set of capabilities. > >> > >> It was however very weak on the semantics of matching. I=20 > eventually=20 > >> got involved because I was interested in it and identified many of=20 > >> the semantic issues. Jonathan and I worked on it for a long time. > >> Eventually, because of some review comments I think,=20 > Jonathan tried=20 > >> to define the semantics using RFC 2533 because it was a=20 > standard that=20 > >> seemed to be at least partially suitable to the task. (In=20 > retrospect=20 > >> this may not have been such a good idea, since it adds an=20 > additional=20 > >> layer of complexity.) > >> > >> RFC 2533 syntax is much richer. But it was not a goal to=20 > provide that=20 > >> richness. (Mapping that all onto SIP header syntax would=20 > be awful.)=20 > >> It was only used as an intermediate form to define the=20 > semantics of=20 > >> the SIP headers. > >> > >> Its understood that there are lots of things one might want to=20 > >> express that you can't express. > >> > >> If you aren't already aware of it, you might want to look=20 > at RFC 4596=20 > >> (Guidelines for Usage of the Session Initiation Protocol=20 > (SIP) Caller=20 > >> Preferences Extension). > >> > >> Paul > >> > >>> If each of the COntact contains alice@atlanta.com wouldnt it be=20 > >>> interpreted as " alice supports duplex audio and oneway video=20 > >>> separatley and not both at the same time". > >>> Actually i'm not quite sure how to represesnt the=20 > predicate in the=20 > >>> Contact header correctly, hence my Queries. It all stems from the=20 > >>> statement which you too noted " There MUST only be one > >> instance of any > >>> feature tag in feature-param." in RFC 3840 > >>> > >>> > >>> Predicate: > >>> ------------ > >>> & ( & (sip.audio) (sip.duplex=3Dfull) ) > >>> ( & (sip.video) (sip.duplex=3Dreceive-only) ) > >>> > >>> regards > >>> Mahesh > >>> ----- Original Message ----- From: "Christer Holmberg"=20 > >>> > >>> To: "Mahesh Anjanappa" ; "Paul Kyzivat"=20 > >>> > >>> Cc: > >>> Sent: Thursday, January 10, 2008 11:30 AM > >>> Subject: RE: [Sip] Question on RFC3840/3841 > >>> > >>> > >>> > >>> Shouldn't each Contact also contain "alice@atlanta.com"? > >>> > >>> Also, why do you have ";" at the end of each Contact? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mahesh Anjanappa [mailto:mahesha@samsung.com] > >>>> Sent: 10. tammikuuta 2008 6:16 > >>>> To: Paul Kyzivat > >>>> Cc: sip@ietf.org; Christer Holmberg > >>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>> > >>>> hi Paul, > >>>> Sorry there is a mistake in Contact header i=20 > described.Following is=20 > >>>> what i wanted to: > >>>> Contact:sip:alice@atlanta.com; > >>>> Contact:audio;duplex=3Dfull; > >>>> Contact:video;duplex=3Drecieve-only; > >>>> > >>>> Thanks > >>>> Mahesh > >>>> ----- Original Message ----- > >>>> From: "Mahesh Anjanappa" > >>>> To: "Paul Kyzivat" > >>>> Cc: ; "Christer Holmberg" > >>>> > >>>> Sent: Wednesday, January 09, 2008 10:48 PM > >>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>> > >>>> > >>>>> Thanks Paul. > >>>>> So would it be right if i have a Contact Headers describing > >>>> Duplex Audio & > >>>>> one-way Video Capabilities as follows? > >>>>> > >>>>> Contact:sip:alice@atlanta.com; > >>>>> Contact:sip:audio;duplex=3Dfull; > >>>>> Contact:sip:video;duplex=3Drecieve-only; > >>>>> > >>>>> NOTE: The Predicate(for above) for which i'm attempting=20 > is & ( &=20 > >>>>> (sip.audio) (sip.duplex=3Dfull) ) > >>>>> ( & (sip.video) (sip.duplex=3Dreceive-only) ) > >>>>> > >>>>> regards > >>>>> Mahesh > >>>>> > >>>>> ----- Original Message ----- > From: "Paul Kyzivat"=20 > >>>> > >>>>> To: "Mahesh Anjanappa" > >>>>> Cc: "Christer Holmberg" ; > >>>> > >>>>> Sent: Wednesday, January 09, 2008 7:55 PM > >>>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>>> > >>>>> > >>>>>> > >>>>>> Mahesh Anjanappa wrote: > >>>>>>> hi > >>>>>>> That is my understanding as well. But if that is the case > >>>> then it should > >>>>>>> apply to Contact header as well > >>>>>>> when describing Capabilities using Feature parameters in > >>>> Contact Header. > >>>>>>> But i'm not sure if it applies the same way. I had posted > >>>> this question > >>>>>>> long ago but didnt get any comments on it. > >>>>>> The rule forbidding multiple instances of a parameter > >>>> applies to all > >>>>>> headers, so it applies to Contact. E.g. the following > >> is illegal: > >>>>>> = Contact:sip:alice@atlanta.com;methods=3D"INVITE";methods=3D"CANCEL" > >>>>>> > >>>>>> Paul > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>>> sipping@ietf.org for new developments on the > >> application of sip > >>>> > >>> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 08:26:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrEr-0007Vl-C8; Fri, 18 Jan 2008 08:26:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFrEq-0007Vf-0F for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:26:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrEp-0007VL-KL for sip@ietf.org; Fri, 18 Jan 2008 08:26:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFrEo-0003EW-2l for sip@ietf.org; Fri, 18 Jan 2008 08:26:27 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6356E21447; Fri, 18 Jan 2008 14:26:25 +0100 (CET) X-AuditID: c1b4fb3e-ac5ebbb0000007e1-71-4790a9010181 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 445C921347; Fri, 18 Jan 2008 14:26:25 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 14:26:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jan 2008 14:26:24 +0100 Message-ID: In-Reply-To: <478633C4.2060209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on RFC3840/3841 - matching of list values Thread-Index: AchTmf6noFFXdaVITfq5Wi/PDr3BpAGFJA+A References: <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> <478629C1.5090404@cisco.com> <478633C4.2060209@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 18 Jan 2008 13:26:24.0803 (UTC) FILETIME=[B9138730:01C859D5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: Subject: [Sip] Question on RFC3840/3841 - matching of list values X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, One question is I have is related to the matching of list values. First, when a user registers the SIP methods is supports, it can be a list of methods (e.g. methods=3D"INVITE, BYE,....) Then, when a request comes, it is automatically assigend an implicit method preference, e.g. (methods=3D"INVITE"). But, what if the request also contains a list of values. Assume the user registers the following feature-tag, with a list of values: myTag=3Da,b Which will generate (| (myTag=3Da) (myTag=3Db)) Now, I can receive the following in the Contact: 1. myTag=3Da,b I assume that is a match 2. myTag=3Da Is that a match? 3. myTag=3Db Is that a match? 4. myTag=3Db,a Is that a match? 5. myTag=3Da,b,c Is that a match? Now, IF it is enough that either a or b in my request is needed for a match, but I want both a AND b to match, I guess I would have to do the following: Accept-Contact:*, myTag=3Da Accept-Contact:*, myTag=3Db (or, Accept-Contact: *;myTag=3Da, *;myTag=3Db ...which would generate: (& (myTag=3Da) (myTag=3Db)) Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 10. tammikuuta 2008 17:04 > To: Christer Holmberg > Cc: Mahesh Anjanappa; sip@ietf.org > Subject: Re: [Sip] Question on RFC3840/3841 >=20 > Christer, >=20 > RFC3840 by itself, without 2533, is *not* sufficient to=20 > understand how to do the matching. >=20 > I put an appendix in RFC 4596 that gives an algorithm without=20 > reference to 2533. I *think* it is right, but of course it is=20 > not normative. >=20 > Note that IMO none of this is intuitive or straightforward.=20 > Every time I get a detailed question on it I have to do a=20 > bunch of review before I can answer it. (But maybe that's=20 > just because I don't have enough neurons left.) >=20 > Paul >=20 > Christer Holmberg wrote: > > Paul, > >=20 > > Regarding the matching, are you saying that reading RFC3840=20 > is enough=20 > > to understand how the matching is done in a "SIP=20 > environment"? Or, do=20 > > I also need to read RFC2533? > >=20 > > I have some questions on the matching, but I will come back to them=20 > > later. I still have some reading to do. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 10. tammikuuta 2008 16:21 > >> To: Mahesh Anjanappa > >> Cc: Christer Holmberg; sip@ietf.org > >> Subject: Re: [Sip] Question on RFC3840/3841 > >> > >> > >> > >> Mahesh Anjanappa wrote: > >>> Yes the ';' is a mistake. But i'm not sure if each=20 > Contact should=20 > >>> contain "alice@atlanta.com" > >> Well, it has to have a URI to be syntactically correct. > >> > >> Your problem is that you are trying to express something=20 > that cannot=20 > >> be expressed with the callee caps syntax. It only maps to=20 > a subset of=20 > >> the syntax supported by RFC 2533. > >> > >>> because the predicate that i'm trying to represent is as follows=20 > >>> meanig to say alice supports a communication which whose > >> capability is > >>> Duplex Audio + One Way Video. > >> You just can't say that. Sorry. > >> > >> A little history may help you to understand, though it won't solve=20 > >> your > >> problem: > >> > >> The initial draft for callerprefs came out a very long=20 > time ago. (The=20 > >> earliest draft I have is -03 which came out in november of=20 > 2000.) It=20 > >> set the basic syntax and the initial set of capabilities. > >> > >> It was however very weak on the semantics of matching. I=20 > eventually=20 > >> got involved because I was interested in it and identified many of=20 > >> the semantic issues. Jonathan and I worked on it for a long time. > >> Eventually, because of some review comments I think,=20 > Jonathan tried=20 > >> to define the semantics using RFC 2533 because it was a=20 > standard that=20 > >> seemed to be at least partially suitable to the task. (In=20 > retrospect=20 > >> this may not have been such a good idea, since it adds an=20 > additional=20 > >> layer of complexity.) > >> > >> RFC 2533 syntax is much richer. But it was not a goal to=20 > provide that=20 > >> richness. (Mapping that all onto SIP header syntax would=20 > be awful.)=20 > >> It was only used as an intermediate form to define the=20 > semantics of=20 > >> the SIP headers. > >> > >> Its understood that there are lots of things one might want to=20 > >> express that you can't express. > >> > >> If you aren't already aware of it, you might want to look=20 > at RFC 4596=20 > >> (Guidelines for Usage of the Session Initiation Protocol=20 > (SIP) Caller=20 > >> Preferences Extension). > >> > >> Paul > >> > >>> If each of the COntact contains alice@atlanta.com wouldnt it be=20 > >>> interpreted as " alice supports duplex audio and oneway video=20 > >>> separatley and not both at the same time". > >>> Actually i'm not quite sure how to represesnt the=20 > predicate in the=20 > >>> Contact header correctly, hence my Queries. It all stems from the=20 > >>> statement which you too noted " There MUST only be one > >> instance of any > >>> feature tag in feature-param." in RFC 3840 > >>> > >>> > >>> Predicate: > >>> ------------ > >>> & ( & (sip.audio) (sip.duplex=3Dfull) ) > >>> ( & (sip.video) (sip.duplex=3Dreceive-only) ) > >>> > >>> regards > >>> Mahesh > >>> ----- Original Message ----- From: "Christer Holmberg"=20 > >>> > >>> To: "Mahesh Anjanappa" ; "Paul Kyzivat"=20 > >>> > >>> Cc: > >>> Sent: Thursday, January 10, 2008 11:30 AM > >>> Subject: RE: [Sip] Question on RFC3840/3841 > >>> > >>> > >>> > >>> Shouldn't each Contact also contain "alice@atlanta.com"? > >>> > >>> Also, why do you have ";" at the end of each Contact? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mahesh Anjanappa [mailto:mahesha@samsung.com] > >>>> Sent: 10. tammikuuta 2008 6:16 > >>>> To: Paul Kyzivat > >>>> Cc: sip@ietf.org; Christer Holmberg > >>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>> > >>>> hi Paul, > >>>> Sorry there is a mistake in Contact header i=20 > described.Following is=20 > >>>> what i wanted to: > >>>> Contact:sip:alice@atlanta.com; > >>>> Contact:audio;duplex=3Dfull; > >>>> Contact:video;duplex=3Drecieve-only; > >>>> > >>>> Thanks > >>>> Mahesh > >>>> ----- Original Message ----- > >>>> From: "Mahesh Anjanappa" > >>>> To: "Paul Kyzivat" > >>>> Cc: ; "Christer Holmberg" > >>>> > >>>> Sent: Wednesday, January 09, 2008 10:48 PM > >>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>> > >>>> > >>>>> Thanks Paul. > >>>>> So would it be right if i have a Contact Headers describing > >>>> Duplex Audio & > >>>>> one-way Video Capabilities as follows? > >>>>> > >>>>> Contact:sip:alice@atlanta.com; > >>>>> Contact:sip:audio;duplex=3Dfull; > >>>>> Contact:sip:video;duplex=3Drecieve-only; > >>>>> > >>>>> NOTE: The Predicate(for above) for which i'm attempting=20 > is & ( &=20 > >>>>> (sip.audio) (sip.duplex=3Dfull) ) > >>>>> ( & (sip.video) (sip.duplex=3Dreceive-only) ) > >>>>> > >>>>> regards > >>>>> Mahesh > >>>>> > >>>>> ----- Original Message ----- > From: "Paul Kyzivat"=20 > >>>> > >>>>> To: "Mahesh Anjanappa" > >>>>> Cc: "Christer Holmberg" ; > >>>> > >>>>> Sent: Wednesday, January 09, 2008 7:55 PM > >>>>> Subject: Re: [Sip] Question on RFC3840/3841 > >>>>> > >>>>> > >>>>>> > >>>>>> Mahesh Anjanappa wrote: > >>>>>>> hi > >>>>>>> That is my understanding as well. But if that is the case > >>>> then it should > >>>>>>> apply to Contact header as well > >>>>>>> when describing Capabilities using Feature parameters in > >>>> Contact Header. > >>>>>>> But i'm not sure if it applies the same way. I had posted > >>>> this question > >>>>>>> long ago but didnt get any comments on it. > >>>>>> The rule forbidding multiple instances of a parameter > >>>> applies to all > >>>>>> headers, so it applies to Contact. E.g. the following > >> is illegal: > >>>>>> = Contact:sip:alice@atlanta.com;methods=3D"INVITE";methods=3D"CANCEL" > >>>>>> > >>>>>> Paul > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>>> sipping@ietf.org for new developments on the > >> application of sip > >>>> > >>> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 08:33:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrM4-0003ee-Rg; Fri, 18 Jan 2008 08:33:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFrM3-0003eY-B1 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:33:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrM3-0003eQ-07 for sip@ietf.org; Fri, 18 Jan 2008 08:33:55 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFrM2-0003Nx-Jm for sip@ietf.org; Fri, 18 Jan 2008 08:33:54 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 08:33:49 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Jan 2008 08:33:50 -0500 From: Bob Penfield To: Jeroen van Bemmel , Christer Holmberg Date: Fri, 18 Jan 2008 08:33:46 -0500 Subject: RE: [Sip] Interesting problem with PRACK and resent INVITEs Thread-Topic: [Sip] Interesting problem with PRACK and resent INVITEs Thread-Index: AchZqIcAfmAtjkdgSquu+hXV1gz50QALO77A Message-ID: References: <200801172023.m0HKNRNa008780@dragon.ariadne.com> <478FFED9.7080307@cisco.com> <4790547E.8000009@zonnet.nl> <47905D04.6050509@zonnet.nl> In-Reply-To: <47905D04.6050509@zonnet.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "sip@ietf.org" , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I believe that a CSeq of 2 is perfectly valid for the second INVITE (resubm= itted with credentials). The RFC 3261 is clear that it should have the same= Call-ID and from-tag. The CSeq number space is per dialog. This second IN= VITE is not part of any dialog, therefore its CSeq should not be compared w= ith any previous dialog. If a UA does keep CSeq state for a Call-ID it should be independent of the = dialog CSeq state, and not updated by in-dialog requests. cheers, (-:bob -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Friday, January 18, 2008 3:02 AM To: Christer Holmberg Cc: sip@ietf.org; Paul Kyzivat Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs Christer, >> . >> >> >> Regarding from tags there is no explicit text, but 22.2 says: >> >> When a UAC resubmits a request with its credentials after receiving a >> 401 (Unauthorized) or 407 (Proxy Authentication Required) response, >> it MUST increment the CSeq header field value as it would normally >> when sending an updated request. >> > > So, I guess that means that the second INVITE in Dale's example should > have Cseq =3D> 3. I interpreted this as "MUST increment (relative to the INVITE being challenged)". I guess for initial INVITEs the minimal requirement is that the CSeq be different, else merged request detection (8.2.2.2) could kick in and prevent the call from succeeding. So both 2 or 3 are valid, the text is ambiguous Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 08:39:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrRR-0004lu-GJ; Fri, 18 Jan 2008 08:39:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFrRP-0004iN-K8 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrRP-0004iF-AY for sip@ietf.org; Fri, 18 Jan 2008 08:39:27 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFrRN-0007vx-Ty for sip@ietf.org; Fri, 18 Jan 2008 08:39:27 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m0IDd9gY026241 for ; Fri, 18 Jan 2008 07:39:25 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 07:39:14 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 14:39:11 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jan 2008 14:39:10 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001B492B5@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Important deadlines for Philadelphia Thread-index: AchZ14E/V4Kkn6WZQfyOWRtzqSzHLg== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 18 Jan 2008 13:39:11.0815 (UTC) FILETIME=[82404570:01C859D7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] Important deadlines for Philadelphia X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG chair) Important dates for Philadelphia are at http://www.ietf.org/meetings/71-cutoff_dates.html The ones we are interested in for progressing the work of the SIP WG are: February 18, Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 ET (22:00 UTC/GMT) February 25, Monday - Internet Draft final submission cut-off by 17:00 ET (22:00 UTC/GMT) If you think you have a WG draft at -00 level that you are submitting, then it would be a good idea to talk to Dean and myself about it before you submit it 3 minutes before the deadline. We recommend you use the automatic submission tool if at all possible, as this minimises the delay in getting your draft visible to the rest of us out here who are all eagerly waiting to read it. It is here: https://datatracker.ietf.org/idst/upload.cgi It helps if you run ID-nits on the document before submission, and correct the problems (that way you have only yourselves to blame if boilerplate errors delay the submission): http://tools.ietf.org/tools/idnits/ Please start thinking about what should be having agenda time. Dean will be issuing his request for slots in due course. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 09:51:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsZA-0004di-Gb; Fri, 18 Jan 2008 09:51:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFsZ8-0004WJ-7r for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:51:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsZ7-0004Vi-Qi for sip@ietf.org; Fri, 18 Jan 2008 09:51:29 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFsZ7-0005N5-5u for sip@ietf.org; Fri, 18 Jan 2008 09:51:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2008 09:51:29 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0IEpSWM031230; Fri, 18 Jan 2008 09:51:28 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0IEp7ui015460; Fri, 18 Jan 2008 14:51:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 09:51:14 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 09:51:13 -0500 Message-ID: <4790BCE5.7060603@cisco.com> Date: Fri, 18 Jan 2008 09:51:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] Questions on draft-rosenberg-sip-ua-loose-route-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 14:51:13.0835 (UTC) FILETIME=[92602FB0:01C859E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4143; t=1200667888; x=1201531888; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Questions=20on=20draft-rosenber g-sip-ua-loose-route-01.txt |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=/fQeaXHrag6aWVvZoDsHWYqUg7OSjNXaQlqn/acjeUM=; b=e9dbg0SsamPACzJoz+JG5hfaKsOUtBTVg8aGAvfqDXu1sXryAFrbgCUX3g BD0oK9407d235N33zfnwzGdjbgQd92vc0py52AyakH5kJ3tZOKvPpJ9Eq1Ns +/WsLbODKG; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been busy so I have been only loosely following this discussion. Hadriel Kaplan wrote: > If I read the draft correctly, the proposed solution is that rerouting action leaves the req-uri alone, and pushes a Route for the resolved target's URI (contact/whatever). Whereas a retargeting action replaces the req-uri with the new target, and possibly pushes the previous req-uri into History-Info. The draft proposes retargeting be defined as when the proxy determines the new target could not claim the previous req-uri as its Identity. In other words, if the new target were to originate a request using the previous req-uri as its From addr-spec, would its domain sign it using rfc4474 - if so then it's a reroute, if not then it's a retarget. Correct? Given dean's terminology the above statement seems a little imprecise. It puts things in only two buckets, not the three or more that Dean proposes. I think that impacts the following. > The draft also describes several cases, some of which don't seem to follow the above rules. > > For example, Section 5 example 3 says: > 3. When a proxy receiving a request identifies a next hop server > that is needed to process the request, that next hop server is a > route. A next hop server is not a UA and would never be able to > claim its identity. Its URI is pushed into a Route header field > and the Request-URI is retained. An important use case for this > are proxies that select PSTN gateways for call egress to the > PSTN. Such selection would place the SIP URI of the gateway into > the topmost Route header field value and retain the Request-URI. The above is also less than precise. > So this says a PSTN gateway could not claim the identity, yet the behavior is still rerouting? There is a problem here one way or another. A PSTN GW *is* a UA. And if the address is a phone number, then it *can* claim identity to it. > Another example of this is in Section 2.6 for Emergency Numbers. It states the SOS URN needs to stay in place in the req-uri all the way to the call-taker. I'm not sure if such a call-taker could claim Identity to an SOS URN, and furthermore the odds are the call-taker is in another domain, which per this draft would constitute a retargeting and change the req-uri. No? I see URNs as much like phone numbers, in that they aren't associated with domains. There semantics are intended to be known publicly, and there may be many different UAs that can claim to be responsible for them. In normal emergency processing, the receiving UA *should* be able to claim identity for that URN. Of course there are technical problems for both phone numbers and URNs in that we don't know how to apply sip identity to them. > This draft should also describe what happens for service invocation, which is a stated problem space in section 2.5. Again, a voicemail system or IVR or App Server could not claim Identity for the req-uri, and thus it would be a retarget per the draft's definition. I think it is debatable whether a VM or IVR system can claim identity for the r-uri. It depends on the deployment and the policies of the owner of that URI. (If I have a phone in my home, listed as belonging to me, and I attach an answering machine to it, that answering machine gets to assert my identity as much as I do. If I contract with a SP to provide my answering services, it can still claim my identity if I want to allow it to do so. Its the same with a human secretary. I can give a secretary an extension on my own AOR, in which case its possible to claim my identity, or I can program my proxy to retarget to the secretary, in which case the identity is different.) Paul > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 09:57:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsen-0004Jb-KU; Fri, 18 Jan 2008 09:57:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFsem-0004H7-Bg for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsel-0004F4-W9 for sip@ietf.org; Fri, 18 Jan 2008 09:57:20 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFsek-00012q-IK for sip@ietf.org; Fri, 18 Jan 2008 09:57:19 -0500 X-IronPort-AV: E=Sophos;i="4.25,216,1199682000"; d="scan'208";a="83763570" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2008 09:57:19 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0IEvICl002194; Fri, 18 Jan 2008 09:57:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0IEv0uq018036; Fri, 18 Jan 2008 14:57:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 09:57:05 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 09:57:05 -0500 Message-ID: <4790BE45.4040804@cisco.com> Date: Fri, 18 Jan 2008 09:57:09 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!) References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <"0D5F89FA C29E2C41B98A6A762007F5D0593C68"@GBNTHT12009MSX.gb002.siemen! s .net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <479058E4.2050902@zonnet.nl> In-Reply-To: <479058E4.2050902@zonnet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 14:57:05.0530 (UTC) FILETIME=[640095A0:01C859E2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=512; t=1200668238; x=1201532238; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20=09Vocabulary=20and=20problem=2 0statement=20for=20Request-URI,=09retargeting,=0A=20and=20SI P=20routing=20(long,=20but=20read=20it!) |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=AjS8Jrj/DJVKlFGq1CHSz76/aYODdxsDVaB2bJNIR7E=; b=ZvksJmvOMEm05rKD8BWUfhCOn5MnxWilq7wbClm2lFhnCBB9XnRqEL54AP eMj8uy9edq3PXOQ1AiR8XAEGtqOmP3GsA5fuJFNcIye9uMSIrBB3HYYiy+Zv K8ZfDzrd2L; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > BTW what happened to the 'opaque' parameter solution that was part of a > GRUU draft some versions ago? A special URI parameter that survives > rerouting/retargeting would avoid introducing yet another identity > header, and also detection-of-support issues. It was judged to be a hack and rejected. That was one of the motivations for the current proposal, which (at the time) was thought to be cleaner. In hindsight maybe it wasn't so much cleaner. :-) Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 10:18:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsyk-0001eO-Ln; Fri, 18 Jan 2008 10:17:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFsyj-0001eD-4M for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsyi-0001e5-Qr for sip@ietf.org; Fri, 18 Jan 2008 10:17:56 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFsyi-0001Re-Fa for sip@ietf.org; Fri, 18 Jan 2008 10:17:56 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 10:17:52 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Jan 2008 10:17:51 -0500 From: Hadriel Kaplan To: "Elwell, John" , Dean Willis , IETF SIP List Date: Fri, 18 Jan 2008 10:15:00 -0500 Subject: RE: [Sip] Vocabulary and problem statement for Request-URI,retargeting, and SIP routing (long, but read it!) Thread-Topic: [Sip] Vocabulary and problem statement for Request-URI,retargeting, and SIP routing (long, but read it!) Thread-Index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrAADtRW8A== Message-ID: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <"0 D5F89FAC29E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey John, Inline... > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, January 18, 2008 2:48 AM > > > > But in the re-targeting scenario such as: > > RTRG RRT > > +---+ +---+ > > |R1 | |R2 | > > B /+---+\ C E /+---+\ F > > RT / \ RT RT / \ RT > > +---+/ \+---+ D +---+/ \+---+ > > |P1 | |P2 +---+P3 | |P4 | > > A /+---+ +---+ +---+ +---+\ G > > / \ > > +---+/ \+---+ > > |UAC| |UAS| > > +---+ +---+ > > > > UA-Loose-routing wants the req-uri seen on connection "C" I think. > > To header gives you A. > > PCPID gives you E. > > Hist-Info gives you A,B,C,D,E,F. > [JRE] According to Dean's definition of RT, it does not change the > Request-URI (only the Route header field presumably, or maybe not even > that). > So C, D and E are the same. Also A and B are the same, and F and G are > the same. > So I think: > - UA-Loose-routing gives you C/D/E > - To gives you A/B > - PCPID gives you C/D/E > - Target gives you C/D/E > - Hist-info gives you A/B, C/D/E and F/G. Yes, I agree that is the *theory*. :) I drew it that way though so we could argue about what the UAS/UALR-draft _= wants_ to happen vs. what _will_ happen if P2 or P3 are not purely RT's and= didn't support a new draft. (Since it seemed the conversation was going th= at way previously on this list, for example when Christer pointed out the d= ifference between Target and PCPID) For example, I think there is more than just a syntax difference between Ch= rister's sip-target-uri-delivery draft (STUD?) and Jonathan's UALR approach= . Though I have no idea which one is better. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 10:28:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFt8h-0005JZ-C1; Fri, 18 Jan 2008 10:28:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFt8g-0005JS-KE for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:28:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFt8g-0005JK-AP for sip@ietf.org; Fri, 18 Jan 2008 10:28:14 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFt8f-0001az-MN for sip@ietf.org; Fri, 18 Jan 2008 10:28:14 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU009A6IZ1NU@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Jan 2008 15:28:13 +0000 (GMT) Date: Fri, 18 Jan 2008 15:28:12 +0000 From: "Elwell, John" Subject: RE: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!) In-reply-to: To: Hadriel Kaplan , Dean Willis , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!) thread-index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrAADtRW8AABPONg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC29 E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, Well, I have been having a side thread with Christer and Hans Erik, and the only difference other than syntax that they could convince me of was support for UAs that do not register, in that with loose-route you would need additional provisioning in the domain proxy to say that the UA (gateway or whatever) supports loose-route. Given that you would need provisioning in the proxy anyway for such UAs, I didn't see this as a big deal, but it is a difference. John=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 18 January 2008 15:15 > To: Elwell, John; Dean Willis; IETF SIP List > Subject: RE: [Sip] Vocabulary and problem statement=20 > forRequest-URI,retargeting, and SIP routing (long, but read it!) >=20 > Hey John, > Inline... >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Friday, January 18, 2008 2:48 AM > > > > > > But in the re-targeting scenario such as: > > > RTRG RRT > > > +---+ +---+ > > > |R1 | |R2 | > > > B /+---+\ C E /+---+\ F > > > RT / \ RT RT / \ RT > > > +---+/ \+---+ D +---+/ \+---+ > > > |P1 | |P2 +---+P3 | |P4 | > > > A /+---+ +---+ +---+ +---+\ G > > > / \ > > > +---+/ \+---+ > > > |UAC| |UAS| > > > +---+ +---+ > > > > > > UA-Loose-routing wants the req-uri seen on connection "C" I think. > > > To header gives you A. > > > PCPID gives you E. > > > Hist-Info gives you A,B,C,D,E,F. > > [JRE] According to Dean's definition of RT, it does not change the > > Request-URI (only the Route header field presumably, or=20 > maybe not even > > that). > > So C, D and E are the same. Also A and B are the same, and=20 > F and G are > > the same. > > So I think: > > - UA-Loose-routing gives you C/D/E > > - To gives you A/B > > - PCPID gives you C/D/E > > - Target gives you C/D/E > > - Hist-info gives you A/B, C/D/E and F/G. >=20 > Yes, I agree that is the *theory*. :) > I drew it that way though so we could argue about what the=20 > UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2=20 > or P3 are not purely RT's and didn't support a new draft.=20 > (Since it seemed the conversation was going that way=20 > previously on this list, for example when Christer pointed=20 > out the difference between Target and PCPID) >=20 > For example, I think there is more than just a syntax=20 > difference between Christer's sip-target-uri-delivery draft=20 > (STUD?) and Jonathan's UALR approach. Though I have no idea=20 > which one is better. >=20 > -hadriel >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 10:55:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtYa-0001ZU-RI; Fri, 18 Jan 2008 10:55:00 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFtYZ-0001ZJ-Ir for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtYZ-0001ZB-9A for sip@ietf.org; Fri, 18 Jan 2008 10:54:59 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFtYY-00027n-Le for sip@ietf.org; Fri, 18 Jan 2008 10:54:59 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 18 Jan 2008 10:54:54 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Jan 2008 10:54:53 -0500 From: Hadriel Kaplan To: "Elwell, John" , Dean Willis , IETF SIP List Date: Fri, 18 Jan 2008 10:52:02 -0500 Subject: RE: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!) Thread-Topic: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!) Thread-Index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrAADtRW8AABPONgAABHrjA= Message-ID: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC29 E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah I like STUD because it's explicit. But the big difference I see is what happens if R1 supports STUD but P2, or= more likely a domain between P2 and P3, Retarget but don't support STUD. = Then R2 gets a Target which is wrong - it's the URI of C vs. D (or somethin= g between D). In other words it could be the target uri of a completely di= fferent user/domain. With UALR, since retargeting proxies already replace the req-uri today, you= 'd get a req-uri which isn't wrong. Even if P2 did Rerouting and not UALR = (ie, still replaced the req-uri but was not really retargeting), the req-ur= i received by R2 wouldn't be totally wrong. It would lose the parameters a= nd info that could have been useful, but it's less likely to cause harm. (m= aybe?) The counter-argument is what happens if P3 doesn't do UALR, but I would thi= nk it's far more likely that an operator of a domain has control over the e= quipment in their domain. Though I'm probably thinking in circles - this whole topic makes my head hu= rt. :) -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, January 18, 2008 10:28 AM > To: Hadriel Kaplan; Dean Willis; IETF SIP List > Subject: RE: [Sip] Vocabulary and problem statement forRequest- > URI,retargeting, and SIP routing (long, but read it!) > > Hadriel, > > Well, I have been having a side thread with Christer and Hans Erik, and > the only difference other than syntax that they could convince me of was > support for UAs that do not register, in that with loose-route you would > need additional provisioning in the domain proxy to say that the UA > (gateway or whatever) supports loose-route. Given that you would need > provisioning in the proxy anyway for such UAs, I didn't see this as a > big deal, but it is a difference. > > John > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 18 January 2008 15:15 > > To: Elwell, John; Dean Willis; IETF SIP List > > Subject: RE: [Sip] Vocabulary and problem statement > > forRequest-URI,retargeting, and SIP routing (long, but read it!) > > > > Hey John, > > Inline... > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Friday, January 18, 2008 2:48 AM > > > > > > > > But in the re-targeting scenario such as: > > > > RTRG RRT > > > > +---+ +---+ > > > > |R1 | |R2 | > > > > B /+---+\ C E /+---+\ F > > > > RT / \ RT RT / \ RT > > > > +---+/ \+---+ D +---+/ \+---+ > > > > |P1 | |P2 +---+P3 | |P4 | > > > > A /+---+ +---+ +---+ +---+\ G > > > > / \ > > > > +---+/ \+---+ > > > > |UAC| |UAS| > > > > +---+ +---+ > > > > > > > > UA-Loose-routing wants the req-uri seen on connection "C" I think. > > > > To header gives you A. > > > > PCPID gives you E. > > > > Hist-Info gives you A,B,C,D,E,F. > > > [JRE] According to Dean's definition of RT, it does not change the > > > Request-URI (only the Route header field presumably, or > > maybe not even > > > that). > > > So C, D and E are the same. Also A and B are the same, and > > F and G are > > > the same. > > > So I think: > > > - UA-Loose-routing gives you C/D/E > > > - To gives you A/B > > > - PCPID gives you C/D/E > > > - Target gives you C/D/E > > > - Hist-info gives you A/B, C/D/E and F/G. > > > > Yes, I agree that is the *theory*. :) > > I drew it that way though so we could argue about what the > > UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2 > > or P3 are not purely RT's and didn't support a new draft. > > (Since it seemed the conversation was going that way > > previously on this list, for example when Christer pointed > > out the difference between Target and PCPID) > > > > For example, I think there is more than just a syntax > > difference between Christer's sip-target-uri-delivery draft > > (STUD?) and Jonathan's UALR approach. Though I have no idea > > which one is better. > > > > -hadriel > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 10:59:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtdN-0005AL-Qy; Fri, 18 Jan 2008 10:59:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFtdL-0005AE-Uv for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:59:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtdL-0005A3-Is for sip@ietf.org; Fri, 18 Jan 2008 10:59:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtdL-00076M-0j for sip@ietf.org; Fri, 18 Jan 2008 10:59:55 -0500 X-IronPort-AV: E=Sophos;i="4.25,217,1199682000"; d="scan'208";a="83772540" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2008 10:59:55 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0IFxrOK027971; Fri, 18 Jan 2008 10:59:53 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0IFvQNc026023; Fri, 18 Jan 2008 15:59:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:59:33 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:59:32 -0500 Message-ID: <4790CCE8.2060605@cisco.com> Date: Fri, 18 Jan 2008 10:59:36 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Vocabulary and problem statement forRequest-URI, retargeting, and SIP routing (long, but read it!) References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC29 E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 15:59:32.0392 (UTC) FILETIME=[1D4E5A80:01C859EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4013; t=1200671993; x=1201535993; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20=09Vocabulary=20and=20problem=2 0statement=09forRequest-URI,retargeting,=0A=20and=20SIP=20ro uting=20(long,=20but=20read=20it!) |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=LEdqRuhd1WwH3GxUdRgaYcs4BEZ4V0arRys59FFVP78=; b=nmjprGtX5W8AfOnOmxb8YS9VpCMYRwQ+HVYEl6V3cLRbf/XPSw6HlkpRPI wRDuxbH9CkpkP6W2EXVBOG7x+I3MhZ7LVdCjogZhEFAuj5ZzdIJJ3b1lHIDw QGRlwuex6j; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Hadriel, > > Well, I have been having a side thread with Christer and Hans Erik, and > the only difference other than syntax that they could convince me of was > support for UAs that do not register, in that with loose-route you would > need additional provisioning in the domain proxy to say that the UA > (gateway or whatever) supports loose-route. Given that you would need > provisioning in the proxy anyway for such UAs, I didn't see this as a > big deal, but it is a difference. In the case of registration, it is indicated by the ;lr param on the contact. In the case of provisioning, you need to provision a contact, so its just a matter of provisioning it with ;lr. That is *still* just provisioning a uri, so its not really a difference. Paul > John > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: 18 January 2008 15:15 >> To: Elwell, John; Dean Willis; IETF SIP List >> Subject: RE: [Sip] Vocabulary and problem statement >> forRequest-URI,retargeting, and SIP routing (long, but read it!) >> >> Hey John, >> Inline... >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens.com] >>> Sent: Friday, January 18, 2008 2:48 AM >>>> But in the re-targeting scenario such as: >>>> RTRG RRT >>>> +---+ +---+ >>>> |R1 | |R2 | >>>> B /+---+\ C E /+---+\ F >>>> RT / \ RT RT / \ RT >>>> +---+/ \+---+ D +---+/ \+---+ >>>> |P1 | |P2 +---+P3 | |P4 | >>>> A /+---+ +---+ +---+ +---+\ G >>>> / \ >>>> +---+/ \+---+ >>>> |UAC| |UAS| >>>> +---+ +---+ >>>> >>>> UA-Loose-routing wants the req-uri seen on connection "C" I think. >>>> To header gives you A. >>>> PCPID gives you E. >>>> Hist-Info gives you A,B,C,D,E,F. >>> [JRE] According to Dean's definition of RT, it does not change the >>> Request-URI (only the Route header field presumably, or >> maybe not even >>> that). >>> So C, D and E are the same. Also A and B are the same, and >> F and G are >>> the same. >>> So I think: >>> - UA-Loose-routing gives you C/D/E >>> - To gives you A/B >>> - PCPID gives you C/D/E >>> - Target gives you C/D/E >>> - Hist-info gives you A/B, C/D/E and F/G. >> Yes, I agree that is the *theory*. :) >> I drew it that way though so we could argue about what the >> UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2 >> or P3 are not purely RT's and didn't support a new draft. >> (Since it seemed the conversation was going that way >> previously on this list, for example when Christer pointed >> out the difference between Target and PCPID) >> >> For example, I think there is more than just a syntax >> difference between Christer's sip-target-uri-delivery draft >> (STUD?) and Jonathan's UALR approach. Though I have no idea >> which one is better. >> >> -hadriel >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 11:06:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtjW-0001FE-Af; Fri, 18 Jan 2008 11:06:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFtjS-0001F4-P1 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:06:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtjS-0001Ev-8s for sip@ietf.org; Fri, 18 Jan 2008 11:06:14 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtjR-0007FZ-DQ for sip@ietf.org; Fri, 18 Jan 2008 11:06:14 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU00C2KKQCFJ@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Jan 2008 16:06:12 +0000 (GMT) Date: Fri, 18 Jan 2008 16:06:12 +0000 From: "Elwell, John" Subject: RE: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!) In-reply-to: To: Hadriel Kaplan , Dean Willis , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05941F2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Vocabulary and problem statement forRequest-URI,retargeting, and SIP routing (long, but read it!) thread-index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrAADtRW8AABPONgAABHrjAAARDLsA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC2 9 E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 18 January 2008 15:52 > To: Elwell, John; Dean Willis; IETF SIP List > Subject: RE: [Sip] Vocabulary and problem statement=20 > forRequest-URI,retargeting, and SIP routing (long, but read it!) >=20 > Yeah I like STUD because it's explicit. > But the big difference I see is what happens if R1 supports=20 > STUD but P2, or more likely a domain between P2 and P3,=20 > Retarget but don't support STUD. Then R2 gets a Target which=20 > is wrong - it's the URI of C vs. D (or something between D). =20 > In other words it could be the target uri of a completely=20 > different user/domain. >=20 > With UALR, since retargeting proxies already replace the=20 > req-uri today, you'd get a req-uri which isn't wrong. Even=20 > if P2 did Rerouting and not UALR (ie, still replaced the=20 > req-uri but was not really retargeting), the req-uri received=20 > by R2 wouldn't be totally wrong. It would lose the=20 > parameters and info that could have been useful, but it's=20 > less likely to cause harm. (maybe?) >=20 > The counter-argument is what happens if P3 doesn't do UALR,=20 > but I would think it's far more likely that an operator of a=20 > domain has control over the equipment in their domain. [JRE] And also, P2 should be just routing on the Route header field, because there is still something in the stack. So it would have to be a misbehaving proxy to get it wrong. But in any case, I thought UALR was meant to be applied only on the last hop (or the last set of hops) from the domain proxy to the UAS, so once you invoke it there should not be any more retargeting or rerouting proxies on the path. Maybe the domain proxy is never able to be certain of this. John >=20 > Though I'm probably thinking in circles - this whole topic=20 > makes my head hurt. :) >=20 > -hadriel >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Friday, January 18, 2008 10:28 AM > > To: Hadriel Kaplan; Dean Willis; IETF SIP List > > Subject: RE: [Sip] Vocabulary and problem statement forRequest- > > URI,retargeting, and SIP routing (long, but read it!) > > > > Hadriel, > > > > Well, I have been having a side thread with Christer and=20 > Hans Erik, and > > the only difference other than syntax that they could=20 > convince me of was > > support for UAs that do not register, in that with=20 > loose-route you would > > need additional provisioning in the domain proxy to say that the UA > > (gateway or whatever) supports loose-route. Given that you=20 > would need > > provisioning in the proxy anyway for such UAs, I didn't see=20 > this as a > > big deal, but it is a difference. > > > > John > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: 18 January 2008 15:15 > > > To: Elwell, John; Dean Willis; IETF SIP List > > > Subject: RE: [Sip] Vocabulary and problem statement > > > forRequest-URI,retargeting, and SIP routing (long, but read it!) > > > > > > Hey John, > > > Inline... > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Friday, January 18, 2008 2:48 AM > > > > > > > > > > But in the re-targeting scenario such as: > > > > > RTRG RRT > > > > > +---+ +---+ > > > > > |R1 | |R2 | > > > > > B /+---+\ C E /+---+\ F > > > > > RT / \ RT RT / \ RT > > > > > +---+/ \+---+ D +---+/ \+---+ > > > > > |P1 | |P2 +---+P3 | |P4 | > > > > > A /+---+ +---+ +---+ +---+\ G > > > > > / \ > > > > > +---+/ =20 > \+---+ > > > > > |UAC| =20 > |UAS| > > > > > +---+ =20 > +---+ > > > > > > > > > > UA-Loose-routing wants the req-uri seen on connection=20 > "C" I think. > > > > > To header gives you A. > > > > > PCPID gives you E. > > > > > Hist-Info gives you A,B,C,D,E,F. > > > > [JRE] According to Dean's definition of RT, it does not=20 > change the > > > > Request-URI (only the Route header field presumably, or > > > maybe not even > > > > that). > > > > So C, D and E are the same. Also A and B are the same, and > > > F and G are > > > > the same. > > > > So I think: > > > > - UA-Loose-routing gives you C/D/E > > > > - To gives you A/B > > > > - PCPID gives you C/D/E > > > > - Target gives you C/D/E > > > > - Hist-info gives you A/B, C/D/E and F/G. > > > > > > Yes, I agree that is the *theory*. :) > > > I drew it that way though so we could argue about what the > > > UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2 > > > or P3 are not purely RT's and didn't support a new draft. > > > (Since it seemed the conversation was going that way > > > previously on this list, for example when Christer pointed > > > out the difference between Target and PCPID) > > > > > > For example, I think there is more than just a syntax > > > difference between Christer's sip-target-uri-delivery draft > > > (STUD?) and Jonathan's UALR approach. Though I have no idea > > > which one is better. > > > > > > -hadriel > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 11:07:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtkG-0001VX-MT; Fri, 18 Jan 2008 11:07:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFtkF-0001VC-NT for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:07:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtkF-0001V4-Do for sip@ietf.org; Fri, 18 Jan 2008 11:07:03 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFtkD-0002M7-Gx for sip@ietf.org; Fri, 18 Jan 2008 11:07:03 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU00C6SKRKFU@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Jan 2008 16:07:00 +0000 (GMT) Date: Fri, 18 Jan 2008 16:06:56 +0000 From: "Elwell, John" Subject: RE: [Sip] Vocabulary and problem statementforRequest-URI, retargeting, and SIP routing (long, but read it!) In-reply-to: <4790CCE8.2060605@cisco.com> To: Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05941F3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Vocabulary and problem statementforRequest-URI, retargeting, and SIP routing (long, but read it!) thread-index: AchZ6zIqxT6HNrh7RHyCD1SykeP3LgAAOZhQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> A <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC29 E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> <4790CCE8.2060605@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, Yes, that was my feeling. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 18 January 2008 16:00 > To: Elwell, John > Cc: Hadriel Kaplan; Dean Willis; IETF SIP List > Subject: Re: [Sip] Vocabulary and problem=20 > statementforRequest-URI,retargeting, and SIP routing (long,=20 > but read it!) >=20 >=20 >=20 > Elwell, John wrote: > > Hadriel, > >=20 > > Well, I have been having a side thread with Christer and=20 > Hans Erik, and > > the only difference other than syntax that they could=20 > convince me of was > > support for UAs that do not register, in that with=20 > loose-route you would > > need additional provisioning in the domain proxy to say that the UA > > (gateway or whatever) supports loose-route. Given that you=20 > would need > > provisioning in the proxy anyway for such UAs, I didn't see=20 > this as a > > big deal, but it is a difference. >=20 > In the case of registration, it is indicated by the ;lr param on the=20 > contact. In the case of provisioning, you need to provision a=20 > contact,=20 > so its just a matter of provisioning it with ;lr. That is=20 > *still* just=20 > provisioning a uri, so its not really a difference. >=20 > Paul >=20 > > John=20 > >=20 > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > >> Sent: 18 January 2008 15:15 > >> To: Elwell, John; Dean Willis; IETF SIP List > >> Subject: RE: [Sip] Vocabulary and problem statement=20 > >> forRequest-URI,retargeting, and SIP routing (long, but read it!) > >> > >> Hey John, > >> Inline... > >> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>> Sent: Friday, January 18, 2008 2:48 AM > >>>> But in the re-targeting scenario such as: > >>>> RTRG RRT > >>>> +---+ +---+ > >>>> |R1 | |R2 | > >>>> B /+---+\ C E /+---+\ F > >>>> RT / \ RT RT / \ RT > >>>> +---+/ \+---+ D +---+/ \+---+ > >>>> |P1 | |P2 +---+P3 | |P4 | > >>>> A /+---+ +---+ +---+ +---+\ G > >>>> / \ > >>>> +---+/ \+---+ > >>>> |UAC| |UAS| > >>>> +---+ +---+ > >>>> > >>>> UA-Loose-routing wants the req-uri seen on connection=20 > "C" I think. > >>>> To header gives you A. > >>>> PCPID gives you E. > >>>> Hist-Info gives you A,B,C,D,E,F. > >>> [JRE] According to Dean's definition of RT, it does not change the > >>> Request-URI (only the Route header field presumably, or=20 > >> maybe not even > >>> that). > >>> So C, D and E are the same. Also A and B are the same, and=20 > >> F and G are > >>> the same. > >>> So I think: > >>> - UA-Loose-routing gives you C/D/E > >>> - To gives you A/B > >>> - PCPID gives you C/D/E > >>> - Target gives you C/D/E > >>> - Hist-info gives you A/B, C/D/E and F/G. > >> Yes, I agree that is the *theory*. :) > >> I drew it that way though so we could argue about what the=20 > >> UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2=20 > >> or P3 are not purely RT's and didn't support a new draft.=20 > >> (Since it seemed the conversation was going that way=20 > >> previously on this list, for example when Christer pointed=20 > >> out the difference between Target and PCPID) > >> > >> For example, I think there is more than just a syntax=20 > >> difference between Christer's sip-target-uri-delivery draft=20 > >> (STUD?) and Jonathan's UALR approach. Though I have no idea=20 > >> which one is better. > >> > >> -hadriel > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 11:46:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuMh-0003RL-3F; Fri, 18 Jan 2008 11:46:47 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFuMf-0003Oc-Gx for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:46:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuMf-0003OS-6t for sip@ietf.org; Fri, 18 Jan 2008 11:46:45 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFuMe-0004Fa-CZ for sip@ietf.org; Fri, 18 Jan 2008 11:46:45 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2008 11:46:44 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0IGkiIO023835; Fri, 18 Jan 2008 11:46:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0IGkVuc004183; Fri, 18 Jan 2008 16:46:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 11:46:34 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 11:46:34 -0500 Message-ID: <4790D7F0.8050405@cisco.com> Date: Fri, 18 Jan 2008 11:46:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Vocabulary and problem statement forRequest-URI, retargeting, and SIP routing (long, but read it!) References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <"CA9998CD4A0 20D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se> <" 0 D5F89FAC2 9 E2 C41B98A6A762007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941F2@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05941F2@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2008 16:46:34.0519 (UTC) FILETIME=[AF6CC270:01C859F1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5347; t=1200674804; x=1201538804; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20=09Vocabulary=20and=20problem=2 0statement=09forRequest-URI,retargeting,=0A=20and=20SIP=20ro uting=20(long,=20but=20read=20it!) |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=j11TPv+yO+QmYRaOFrGs8K/yOwJp+cVmkAaKIHiaYQU=; b=rjPj7tRRz7gzmoltE8LHxl1ROKjcurjzpxxeWB/+rZ0JGAYMvHo3LUGmFx 6xW1uBPvzXANopu7ztfKHx9m/GSJSIKQKsq5XIYVAOngORkCI6hBkaUXNIuX 2KYlhktZKM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > [JRE] And also, P2 should be just routing on the Route header field, > because there is still something in the stack. So it would have to be a > misbehaving proxy to get it wrong. I had always assumed that as long as there was something in the Route stack the R-URI would be left alone. But if you read 3261 carefully it nowhere says that. The rules for doing translations on the R-URI (if you are responsible for it) are independent of the routing rules. So it seems valid (maybe mandatory, though that isn't clear to me) that you might translate the R-URI even though there is a Route header, and *then* route based on the Route header. Paul > But in any case, I thought UALR was meant to be applied only on the last > hop (or the last set of hops) from the domain proxy to the UAS, so once > you invoke it there should not be any more retargeting or rerouting > proxies on the path. Maybe the domain proxy is never able to be certain > of this. > > John > >> Though I'm probably thinking in circles - this whole topic >> makes my head hurt. :) >> >> -hadriel >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens.com] >>> Sent: Friday, January 18, 2008 10:28 AM >>> To: Hadriel Kaplan; Dean Willis; IETF SIP List >>> Subject: RE: [Sip] Vocabulary and problem statement forRequest- >>> URI,retargeting, and SIP routing (long, but read it!) >>> >>> Hadriel, >>> >>> Well, I have been having a side thread with Christer and >> Hans Erik, and >>> the only difference other than syntax that they could >> convince me of was >>> support for UAs that do not register, in that with >> loose-route you would >>> need additional provisioning in the domain proxy to say that the UA >>> (gateway or whatever) supports loose-route. Given that you >> would need >>> provisioning in the proxy anyway for such UAs, I didn't see >> this as a >>> big deal, but it is a difference. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: 18 January 2008 15:15 >>>> To: Elwell, John; Dean Willis; IETF SIP List >>>> Subject: RE: [Sip] Vocabulary and problem statement >>>> forRequest-URI,retargeting, and SIP routing (long, but read it!) >>>> >>>> Hey John, >>>> Inline... >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>> Sent: Friday, January 18, 2008 2:48 AM >>>>>> But in the re-targeting scenario such as: >>>>>> RTRG RRT >>>>>> +---+ +---+ >>>>>> |R1 | |R2 | >>>>>> B /+---+\ C E /+---+\ F >>>>>> RT / \ RT RT / \ RT >>>>>> +---+/ \+---+ D +---+/ \+---+ >>>>>> |P1 | |P2 +---+P3 | |P4 | >>>>>> A /+---+ +---+ +---+ +---+\ G >>>>>> / \ >>>>>> +---+/ >> \+---+ >>>>>> |UAC| >> |UAS| >>>>>> +---+ >> +---+ >>>>>> UA-Loose-routing wants the req-uri seen on connection >> "C" I think. >>>>>> To header gives you A. >>>>>> PCPID gives you E. >>>>>> Hist-Info gives you A,B,C,D,E,F. >>>>> [JRE] According to Dean's definition of RT, it does not >> change the >>>>> Request-URI (only the Route header field presumably, or >>>> maybe not even >>>>> that). >>>>> So C, D and E are the same. Also A and B are the same, and >>>> F and G are >>>>> the same. >>>>> So I think: >>>>> - UA-Loose-routing gives you C/D/E >>>>> - To gives you A/B >>>>> - PCPID gives you C/D/E >>>>> - Target gives you C/D/E >>>>> - Hist-info gives you A/B, C/D/E and F/G. >>>> Yes, I agree that is the *theory*. :) >>>> I drew it that way though so we could argue about what the >>>> UAS/UALR-draft _wants_ to happen vs. what _will_ happen if P2 >>>> or P3 are not purely RT's and didn't support a new draft. >>>> (Since it seemed the conversation was going that way >>>> previously on this list, for example when Christer pointed >>>> out the difference between Target and PCPID) >>>> >>>> For example, I think there is more than just a syntax >>>> difference between Christer's sip-target-uri-delivery draft >>>> (STUD?) and Jonathan's UALR approach. Though I have no idea >>>> which one is better. >>>> >>>> -hadriel >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 18 12:14:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFunN-0004bg-A8; Fri, 18 Jan 2008 12:14:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFunM-0004Zh-19 for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:14:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFunL-0004ZX-MO for sip@ietf.org; Fri, 18 Jan 2008 12:14:19 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFunL-00029D-8A for sip@ietf.org; Fri, 18 Jan 2008 12:14:19 -0500 Received: by fg-out-1718.google.com with SMTP id 16so1175288fgg.41 for ; Fri, 18 Jan 2008 09:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=a2evky9GhG7F2MygMZYA/U1KToVd5UhOhDev5pXaWIg=; b=PrDYmX2Lgv4yL9HQCYOvwNQT+/3Dx91BvTpd32Pi5+oOHzJNWcMi8I7vjCm8QiJI2T8z05vdXgBDJb/lT4h2AOz0sz9MWwICCXadWna1Gr13ylYEReqaAGqg4hmtrnjdrofcfkSNdexjukzRfIl/nyRwbphSfC8+sI8N3NOAtnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=UkJKW/zeqkfXtmJaVFFOZd7pGHTie60LzeOfcKNC5t2XgcopGeHaOjqXeKWzMNmEU0iD6K33KU5M1Nyu7ry4SlDHjOBTO3gaNYF0puaDaPp1FMseJ7J4OgI+VyeDBWcO5jXw4I8E5QWyvqDXTsINR6nV1pSCI/qTQnfdm5H4W0k= Received: by 10.86.71.1 with SMTP id t1mr3260413fga.69.1200676458256; Fri, 18 Jan 2008 09:14:18 -0800 (PST) Received: by 10.86.96.2 with HTTP; Fri, 18 Jan 2008 09:14:18 -0800 (PST) Message-ID: Date: Sat, 19 Jan 2008 00:14:18 +0700 From: "Jati Kalingga Praja" To: sip@ietf.org, sip-implementors@lists.cs.columbia.edu, megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Sip] Translation address mechanism from megaco to sip and vice versa X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2123288452==" Errors-To: sip-bounces@ietf.org --===============2123288452== Content-Type: multipart/alternative; boundary="----=_Part_2790_31452674.1200676458223" ------=_Part_2790_31452674.1200676458223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, right now, i'm studying about interworking between megaco and sip. I would like to know about translation address mechanism from megaco to sip and vice versa. I've been searching on internet, but i haven't found the right reference. Anyone can help me? Thx before in advance Regards, Jati ------=_Part_2790_31452674.1200676458223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

right now, i'm studying about interworking between megaco and sip. I would like to know about translation address mechanism from megaco to sip and vice versa. I've been searching on internet, but i haven't found the right reference. Anyone can help me?

Thx before in advance

Regards,

Jati
------=_Part_2790_31452674.1200676458223-- --===============2123288452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2123288452==-- From sip-bounces@ietf.org Sun Jan 20 11:10:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGck6-0005BR-TJ; Sun, 20 Jan 2008 11:09:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JGck5-0005BK-O5 for sip-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 11:09:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGck5-0005BC-DT for Sip@ietf.org; Sun, 20 Jan 2008 11:09:53 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGck4-0007mB-WB for Sip@ietf.org; Sun, 20 Jan 2008 11:09:53 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2008 08:09:49 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0KG9nUa012184; Sun, 20 Jan 2008 08:09:49 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0KG9niX006925; Sun, 20 Jan 2008 16:09:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jan 2008 08:09:49 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.114.102]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jan 2008 08:09:48 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 20 Jan 2008 07:42:39 -0600 To: "Karl Heinz Wolf" , Sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Re: SIP Location Conveyance revved (-09) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jan 2008 16:09:49.0040 (UTC) FILETIME=[E1AEDF00:01C85B7E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1560; t=1200845389; x=1201709389; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20SIP=20Location=20Convey ance=20revved=20(-09) |Sender:=20; bh=j5CIYl36MUTtyGS81oOtaURbFikOr4WOS5pNvcDVaOU=; b=aH8Mcfe5IZy45JrU/U7GlHNrvL3Bs5zji8nwH5I8fG3m8r+d7N55o3HSLQ qDYo2/JyLyrmiCLAwOa9Z4tpvDbba5VpNVZ2GwPp0f3S+D+F7ZU1gTgaT9Fe duE2hqE3M4; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Karl Good catch. I also noticed an incorrect word in what you quoted (entry instead of entity). I added text to the bottom of this paragraph indicating the "inserted-by" parameter is necessary for any location inserting entity. Hopefully I will finish -10 soon (there were a lot of changes because of what was said in Vancouver) and submit it for review... ;-) James At 08:39 AM 1/7/2008, Karl Heinz Wolf wrote: >by James M. Polk Nov 21, 2007; 09:56pm >< - made "inserted-by=" a mandatory header parameter. This is because >< there is a comparable header for errors that needs this parameter's >< value. I'll mention that in a bit. > > >Hi James, > >I just had a look at the draft because of the "inserted-by" parameter >and noticed the following inconsistency: > >Section 3 says: > > The Geolocation header can have parameters that are associated > with a URI in the header field. The "inserted-by" parameter has > values of "endpoint" or "server", indicating which entry added > location to the message. This header parameter MAY be added every > time a new location is added into a message. > >But below it is a "must" and the parameter contains the host name. > >-karl heinz > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 21 09:03:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGxEy-0000US-AG; Mon, 21 Jan 2008 09:03:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JGxEx-0000UM-B8 for sip-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 09:03:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGxEw-0000UE-VT for sip@ietf.org; Mon, 21 Jan 2008 09:03:07 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGxEw-0007mK-7a for sip@ietf.org; Mon, 21 Jan 2008 09:03:06 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 744C721104; Mon, 21 Jan 2008 15:03:04 +0100 (CET) X-AuditID: c1b4fb3e-ab5e9bb0000007e1-7e-4794a6181061 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5A5B8203A0; Mon, 21 Jan 2008 15:03:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 15:03:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Vocabulary and problem statementforRequest-URI, retargeting, and SIP routing (long, but read it!) Date: Mon, 21 Jan 2008 15:03:02 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Vocabulary and problem statementforRequest-URI, retargeting, and SIP routing (long, but read it!) Thread-Index: AchZPU+/dzx0k6eGS1WWuhtw80L2kAADrUvgABZyvrAADtRW8AABPONgAJQFFoA= References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com><47878B1E.3010303@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com><478CEFB4.6070002@zonnet.nl>A <"CA9998CD4A020D418654FCDEF4E707DF04173CB8"@esealmw113.eemea.ericsson.se><" 0 D5F89 FAC29 E2 C41B98A6A762 007F5D0593CFF"@GBNTHT12009MSX.gb002.siemens.net> A<0D5F89FAC29E2C41B98A6A762007F5D0593E13@GBNTHT12009MSX.gb002.siemens.net><0D5F89FAC29E2C41B98A6A762007F5D0594068@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D05941CF@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Hadriel Kaplan" , "Dean Willis" , "IETF SIP List" X-OriginalArrivalTime: 21 Jan 2008 14:03:03.0941 (UTC) FILETIME=[571A9B50:01C85C36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >Well, I have been having a side thread with Christer and Hans=20 >Erik, and the only difference other than syntax that they=20 >could convince me of was support for UAs that do not=20 >register, in that with loose-route you would need additional=20 >provisioning in the domain proxy to say that the UA (gateway=20 >or whatever) supports loose-route. Given that you would need=20 >provisioning in the proxy anyway for such UAs, I didn't see=20 >this as a big deal, but it is a difference. It's strange that we have convinced you about that, since it not the use-case we have been talking about... :) Regards, Christer > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 18 January 2008 15:15 > > To: Elwell, John; Dean Willis; IETF SIP List > > Subject: RE: [Sip] Vocabulary and problem statement=20 > > forRequest-URI,retargeting, and SIP routing (long, but read it!) > >=20 > > Hey John, > > Inline... > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Friday, January 18, 2008 2:48 AM > > > > > > > > But in the re-targeting scenario such as: > > > > RTRG RRT > > > > +---+ +---+ > > > > |R1 | |R2 | > > > > B /+---+\ C E /+---+\ F > > > > RT / \ RT RT / \ RT > > > > +---+/ \+---+ D +---+/ \+---+ > > > > |P1 | |P2 +---+P3 | |P4 | > > > > A /+---+ +---+ +---+ +---+\ G > > > > / \ > > > > +---+/ \+---+ > > > > |UAC| |UAS| > > > > +---+ +---+ > > > > > > > > UA-Loose-routing wants the req-uri seen on connection=20 > "C" I think. > > > > To header gives you A. > > > > PCPID gives you E. > > > > Hist-Info gives you A,B,C,D,E,F. > > > [JRE] According to Dean's definition of RT, it does not=20 > change the=20 > > > Request-URI (only the Route header field presumably, or > > maybe not even > > > that). > > > So C, D and E are the same. Also A and B are the same, and > > F and G are > > > the same. > > > So I think: > > > - UA-Loose-routing gives you C/D/E > > > - To gives you A/B > > > - PCPID gives you C/D/E > > > - Target gives you C/D/E > > > - Hist-info gives you A/B, C/D/E and F/G. > >=20 > > Yes, I agree that is the *theory*. :) I drew it that way=20 > though so we=20 > > could argue about what the UAS/UALR-draft _wants_ to happen=20 > vs. what=20 > > _will_ happen if P2 or P3 are not purely RT's and didn't=20 > support a new=20 > > draft. > > (Since it seemed the conversation was going that way previously on=20 > > this list, for example when Christer pointed out the difference=20 > > between Target and PCPID) > >=20 > > For example, I think there is more than just a syntax difference=20 > > between Christer's sip-target-uri-delivery draft > > (STUD?) and Jonathan's UALR approach. Though I have no=20 > idea which one=20 > > is better. > >=20 > > -hadriel > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 21 15:24:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3C1-00053b-5U; Mon, 21 Jan 2008 15:24:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JH3C0-00053F-8m for sip-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 15:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3Bz-000534-V3 for sip@ietf.org; Mon, 21 Jan 2008 15:24:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH3Bz-00046T-L6 for sip@ietf.org; Mon, 21 Jan 2008 15:24:27 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 258C32136D for ; Mon, 21 Jan 2008 21:24:27 +0100 (CET) X-AuditID: c1b4fb3e-addeebb0000007e1-a2-4794ff7b921c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 17604200BC for ; Mon, 21 Jan 2008 21:24:27 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 21:24:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jan 2008 21:24:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on 3841: extracting implicit preferences Thread-Index: AchcaqPUBju/kaPyS6uKZKKScMRefA== From: "Christer Holmberg" To: X-OriginalArrivalTime: 21 Jan 2008 20:24:26.0799 (UTC) FILETIME=[9E59A3F0:01C85C6B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Question on 3841: extracting implicit preferences X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 The text in chapter 7.2.2 of 3841 says: =20 "If, and only if, the proxy did not find any explicit preferences in the request (because there was no Accept-Contact or Reject-Contact header field), the proxy extracts implicit preferences." =20 Is this really true? My understanding is that e.g. the method preference = is always implcitly set, even if there are A-C/R-C header field(s) in = the request. =20 Shouldn't the text say that if a specific preference wasn't explicitly = set, it will be implicity set? =20 Regards, =20 Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 22 19:16:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTHw-0004av-N7; Tue, 22 Jan 2008 19:16:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHTHu-0004Zc-Mr for sip-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 19:16:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTHu-0004ZB-A6 for sip@ietf.org; Tue, 22 Jan 2008 19:16:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHTHt-00088O-RR for sip@ietf.org; Tue, 22 Jan 2008 19:16:18 -0500 X-IronPort-AV: E=Sophos;i="4.25,235,1199692800"; d="scan'208";a="3800708" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 22 Jan 2008 16:16:17 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0N0GHCf001487; Tue, 22 Jan 2008 16:16:17 -0800 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0N0G73V019393; Wed, 23 Jan 2008 00:16:16 GMT From: "Dan Wing" To: Date: Tue, 22 Jan 2008 16:16:07 -0800 Message-ID: <40d201c85d55$2bd93e40$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchdVSX9zM3HL7oLThuvbkp7Rvd/5w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=790; t=1201047377; x=1201911377; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20updates=20to=20media-security-requirements |Sender:=20; bh=FFq4SpxRdTqT3k/ToQ+Xcy6VlpAsAghDrTenYcbWhmY=; b=mzDghn9/oAN8SE9OY/CeR0071vLbXkxWrrCDr1KEgayz24lqKyLXgkP5Xz jn4SKSa6sUvWtJ6cx2Pf9xZFIU4T9Z6+UWNqaSlD01SXdJ8nFTtzyJbZQ7fY PQChgnVaGA; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Francois Audet' , "'Fries, Steffen'" Subject: [Sip] updates to media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At long last, what everyone has been waiting for: -02 of draft-ietf-sip-media-security-requirements has been submitted. Changes from -01 include: * changing requirement numbers to mnemonics (see Appendix E for details) * added discussion discussing re-use of cryptographic context to aid performance; this is now a 'protocol MUST support' and 'SHOULD implement' requirement. * removed requirement to upgrade from RTP to SRTP, as the requirement was never sufficiently clear. * added more text around several of the requirements. * fixed some nits. Differences from -01 and -02 are at this link (rfcdiff): http://tinyurl.com/26zajs Please reply if you have any comments on these changes. I will ask the chairs to start a WGLC soon. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 22 19:20:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTM3-0003PH-2g; Tue, 22 Jan 2008 19:20:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHTM1-0003P0-1Z for sip-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 19:20:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTM0-0003Or-Kl; Tue, 22 Jan 2008 19:20:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHTM0-0008Gn-7m; Tue, 22 Jan 2008 19:20:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DD2E2175AB; Wed, 23 Jan 2008 00:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHTLV-0008J5-Dh; Tue, 22 Jan 2008 19:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 Jan 2008 19:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-media-security-requirements-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Requirements and Analysis of Media Security Management Protocols Author(s) : D. Wing, et al. Filename : draft-ietf-sip-media-security-requirements-02.txt Pages : 46 Date : 2008-01-22 This documents describes requirements for a protocol to negotiate a security context for SIP-signaled SRTP media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-media-security-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-media-security-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-22191222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-media-security-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-media-security-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-22191222.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 23 04:34:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbzi-00031c-1u; Wed, 23 Jan 2008 04:34:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHbzg-00031O-Et for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbzf-00031C-JX for sip@ietf.org; Wed, 23 Jan 2008 04:34:03 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHbze-0001HG-N6 for sip@ietf.org; Wed, 23 Jan 2008 04:34:03 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id m0N9Y1Ft026376 for ; Wed, 23 Jan 2008 10:34:01 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id m0N9Y1U1000271 for ; Wed, 23 Jan 2008 10:34:01 +0100 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jan 2008 10:34:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C85DA3.15D79A1D" Subject: [Sip] End-to-end security for DTLS-SRTP (FW: I-D Action:draft-fischer-sip-e2e-sec-media-00.txt) Date: Wed, 23 Jan 2008 10:33:57 +0100 Message-ID: <198A10EC585EC74687BCA414E2A5971801FD49B7@MCHP7RDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] End-to-end security for DTLS-SRTP (FW: I-D Action:draft-fischer-sip-e2e-sec-media-00.txt) Thread-Index: AchdoYOBj7k5YqdfRt26nwywkqFi4gAAD1sg From: "Fischer, Kai" To: X-OriginalArrivalTime: 23 Jan 2008 09:34:01.0203 (UTC) FILETIME=[161BC430:01C85DA3] X-Spam-Score: -4.0 (----) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DA3.15D79A1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have submitted a draft proposing a solution to secure a DTLS-SRTP handshake and hence SRTP end-to-end (in terms of end-domain to end-domain). As discussed during the last IETF meetings and analyzed by Dan's Identity-Media draft, current solutions like SIP Identity do not protect the authenticity of the fingerprint end-to-end in certain inter-domain scenarios. For example, a modification of SDP m-/c-lines or the From header field by intermediaries breaks the SIP-Identity or Identity-Media signature and causes a re-signing by a domain different to the originating one. The draft proposes a solution for such scenarios without the need to re-sign during domain traversal and which preserves the original identity information. I appreciate your comments and opinions to the draft and the proposed solution. Kai > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Mittwoch, 23. Januar 2008 10:20 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-fischer-sip-e2e-sec-media-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : End-to-End Security for DTLS-SRTP > Author(s) : K. Fischer > Filename : draft-fischer-sip-e2e-sec-media-00.txt > Pages : 14 > Date : 2008-01-23 >=20 > The end-to-end security properties of DTLS-SRTP depend on the > authenticity of the certificate fingerprint exchanged in the > signalling channel. In current approaches the authenticity is > protected by SIP-Identity or SIP-Identity-Media. These types of > signatures are broken if intermediaries like Session Border > Controllers in other domains change specific information of the SIP > header or the SIP body. The end-to-end security property between the > originating and terminating domain is lost if these intermediaries > re-sign the SIP message and create a new identity signature using > their own domain credentials. >=20 > This document defines a new signature type 'Fingerprint-Identity' > which is exchanged in the signalling channel. Fingerprint-Identity > covers only those elements of a SIP message necessary to authenticate > the certificate fingerprint and to secure media end-to-end. It is > independent from SIP-Identity and SIP-Identity-Media and can be > applied in parallel to them. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fischer-sip-e2e-sec- > media-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-fischer-sip-e2e-sec-media-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-fischer-sip-e2e-sec-media-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01C85DA3.15D79A1D Content-Type: application/octet-stream; name="ATT2550607.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT2550607.TXT Content-Disposition: attachment; filename="ATT2550607.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwOC0wMS0yMzA0MTgzOS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maXNjaGVyLXNpcC1lMmUt c2VjLW1lZGlhLTAwLnR4dA0K ------_=_NextPart_001_01C85DA3.15D79A1D Content-Type: application/octet-stream; name="draft-fischer-sip-e2e-sec-media-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-fischer-sip-e2e-sec-media-00.URL Content-Disposition: attachment; filename="draft-fischer-sip-e2e-sec-media-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1maXNjaGVyLXNpcC1lMmUtc2VjLW1lZGlhLTAwLnR4dA0K ------_=_NextPart_001_01C85DA3.15D79A1D Content-Type: text/plain; name="ATT2550608.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2550608.txt Content-Disposition: attachment; filename="ATT2550608.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C85DA3.15D79A1D Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C85DA3.15D79A1D-- From sip-bounces@ietf.org Wed Jan 23 14:30:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIS-0004ds-AO; Wed, 23 Jan 2008 14:30:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHlIQ-0004dj-OH for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 14:30:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIQ-0004d5-CK; Wed, 23 Jan 2008 14:30:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHlIQ-00040b-0Q; Wed, 23 Jan 2008 14:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E74972AC73; Wed, 23 Jan 2008 19:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHlIP-0005Lc-Mx; Wed, 23 Jan 2008 14:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 23 Jan 2008 14:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-body-handling-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Message Body Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sip-body-handling-01.txt Pages : 17 Date : 2008-01-23 This document specifies how message bodies are handled in SIP. Additionally, it specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-body-handling-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-body-handling-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtheFrom sip-bounces@ietf.org Wed Jan 23 14:30:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIS-0004ds-AO; Wed, 23 Jan 2008 14:30:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHlIQ-0004dj-OH for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 14:30:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIQ-0004d5-CK; Wed, 23 Jan 2008 14:30:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHlIQ-00040b-0Q; Wed, 23 Jan 2008 14:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E74972AC73; Wed, 23 Jan 2008 19:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHlIP-0005Lc-Mx; Wed, 23 Jan 2008 14:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 23 Jan 2008 14:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-body-handling-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Message Body Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sip-body-handling-01.txt Pages : 17 Date : 2008-01-23 This document specifies how message bodies are handled in SIP. Additionally, it specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-body-handling-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-body-handling-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-23142430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-body-handling-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-body-handling-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-23142430.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 23 14:30:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIX-0004fB-Kr; Wed, 23 Jan 2008 14:30:09 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHlIV-0004eX-TV for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 14:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIV-0004eO-JV for sip@ietf.org; Wed, 23 Jan 2008 14:30:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHlIU-0002MM-3d for sip@ietf.org; Wed, 23 Jan 2008 14:30:07 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3B91820A42 for ; Wed, 23 Jan 2008 20:28:39 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-30-47979567efa1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 27DF1204C3 for ; Wed, 23 Jan 2008 20:28:39 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 20:28:39 +0100 Received: from [131.160.126.59] ([131.160.126.59]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 20:28:38 +0100 Message-ID: <47979565.2050700@ericsson.com> Date: Wed, 23 Jan 2008 21:28:37 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2008 19:28:38.0718 (UTC) FILETIME=[279085E0:01C85DF6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] New version of draft-ietf-sip-body-handling-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, I have put together a new version of the body handling draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-01.txt This version addresses all the comments we got in its APPS review, which included modifying the structure of the document. With respect to references to body parts, per the guidelines we got from the APPS people, the document now only allows forward references. Comments are welcome. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip TrAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-23142430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-body-handling-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-body-handling-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-23142430.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jan 23 14:30:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIX-0004fB-Kr; Wed, 23 Jan 2008 14:30:09 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHlIV-0004eX-TV for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 14:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHlIV-0004eO-JV for sip@ietf.org; Wed, 23 Jan 2008 14:30:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHlIU-0002MM-3d for sip@ietf.org; Wed, 23 Jan 2008 14:30:07 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3B91820A42 for ; Wed, 23 Jan 2008 20:28:39 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-30-47979567efa1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 27DF1204C3 for ; Wed, 23 Jan 2008 20:28:39 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 20:28:39 +0100 Received: from [131.160.126.59] ([131.160.126.59]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 20:28:38 +0100 Message-ID: <47979565.2050700@ericsson.com> Date: Wed, 23 Jan 2008 21:28:37 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2008 19:28:38.0718 (UTC) FILETIME=[279085E0:01C85DF6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] New version of draft-ietf-sip-body-handling-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, I have put together a new version of the body handling draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-01.txt This version addresses all the comments we got in its APPS review, which included modifying the structure of the document. With respect to references to body parts, per the guidelines we got from the APPS people, the document now only allows forward references. Comments are welcome. Cheers, 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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip his list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 23 19:49:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqH4-00037y-Pu; Wed, 23 Jan 2008 19:48:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHqH3-00037o-QV for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 19:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqH3-00036m-F3 for sip@ietf.org; Wed, 23 Jan 2008 19:48:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHqH2-0005Lz-Pj for sip@ietf.org; Wed, 23 Jan 2008 19:48:57 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Jan 2008 16:48:56 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0O0muOH013242 for ; Wed, 23 Jan 2008 16:48:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m0O0mtJ7008199 for ; Thu, 24 Jan 2008 00:48:56 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 16:48:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jan 2008 16:48:09 -0800 Message-ID: <378E78E5F361564BB066432F6415764B05218ED5@xmb-sjc-228.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question on refresh request to trigger full state notification thread-index: AcheIsnxLGDXVMJRT9GBqdD5Q44yPQ== From: "Ramamoorthy Subramanian (ramsubra)" To: X-OriginalArrivalTime: 24 Jan 2008 00:48:52.0555 (UTC) FILETIME=[E3E761B0:01C85E22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3617; t=1201135736; x=1201999736; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ramsubra@cisco.com; z=From:=20=22Ramamoorthy=20Subramanian=20(ramsubra)=22=20 |Subject:=20question=20on=20refresh=20request=20to=20trigge r=20full=20state=20notification |Sender:=20; bh=+BqAwlM3216OCq8YbPn6pDtg7tCuoR3YbFbEwqZqRDI=; b=OIsBGkWI5k9q0HGgSi6SV3xJFHqr8d0vv/i11x2TTZijaKExBkWNSeHLJ5 boJRV9izP3F8bXcHJceE97vIdnnyCtaN+r69itF10F+rIKlJhzGHYr1UEBpQ DZf1ZEPcgl; Authentication-Results: sj-dkim-3; header.From=ramsubra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [Sip] question on refresh request to trigger full state notification X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0781331383==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0781331383== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85E22.E3C462C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85E22.E3C462C7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable We're implementing RFC4662 and wondering how to trigger full state notification. The spec says as follows. =20 "Immediate notifications triggered as a result of subsequent SUBSCRIBE messages SHOULD include an RLMI document in which the full state is indicated. The RLS SHOULD also include state information for all resources in the list for which the RLS has state, subject to policy restrictions. This allows the subscriber to refresh their state, and to recover from lost notifications." =20 This is not clear to me. Does this mean the subscriber needs to send a refresh request by including RLMI doc? I guess, not. According to RFC3265, I think, you cant do this. If this means that the subscribe should send another subscribe request (resubscribe) to get the full-state notification? What am I missing here? Is there a simple way to request a full-state notification by subscriber? =20 Thanks, =20 -rama =20 ------_=_NextPart_001_01C85E22.E3C462C7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
We're = implementing=20 RFC4662 and wondering how to trigger full state notification. The spec = says as=20 follows.
 
"Immediate=20 notifications triggered as a result of subsequent = SUBSCRIBE messages SHOULD=20 include an RLMI document in which the full state = is  indicated. =20 The RLS SHOULD also include state information for = all  resources in=20 the list for which the RLS has state, subject to policy =20 restrictions.  This allows the subscriber to refresh their state,=20 and    to recover from lost = notifications."
 
This is not = clear to me.=20 Does this mean the subscriber needs to send a refresh request by = including RLMI=20 doc?  I guess, not. According to RFC3265, I think, you cant do = this.=20 If this means that the subscribe should send another subscribe request=20 (resubscribe) to get the full-state notification? What am I missing = here? Is=20 there a simple way to request a full-state notification by=20 subscriber?
 
Thanks,
 
-rama
 

------_=_NextPart_001_01C85E22.E3C462C7-- --===============0781331383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0781331383==-- From sip-bounces@ietf.org Wed Jan 23 21:11:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHrZA-0004sU-FE; Wed, 23 Jan 2008 21:11:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHrZ8-0004sI-Bs for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 21:11:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHrZ8-0004s4-1B for sip@ietf.org; Wed, 23 Jan 2008 21:11:42 -0500 Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHrZ7-0002ir-JQ for sip@ietf.org; Wed, 23 Jan 2008 21:11:41 -0500 Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA01.westchester.pa.mail.comcast.net with comcast id gooW1Y0040ldTLk0506w00; Thu, 24 Jan 2008 02:11:41 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA04.westchester.pa.mail.comcast.net with comcast id gqBg1Y0070umElk3Q00000; Thu, 24 Jan 2008 02:11:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=3H2CTWD0nD0A:10 a=eALAE6kVaKMtgLHhJ4IA:9 a=u6BMvaB65fM_PXBX6mcA:7 a=qbUOUZeun23_AF4s8Bo44_5syH8A:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m0O2Be07027383 for ; Wed, 23 Jan 2008 21:11:40 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m0O2BeHt027379; Wed, 23 Jan 2008 21:11:40 -0500 Date: Wed, 23 Jan 2008 21:11:40 -0500 Message-Id: <200801240211.m0O2BeHt027379@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <378E78E5F361564BB066432F6415764B05218ED5@xmb-sjc-228.amer.cisco.com> (ramsubra@cisco.com) Subject: Re: [Sip] question on refresh request to trigger full state notification References: <378E78E5F361564BB066432F6415764B05218ED5@xmb-sjc-228.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Ramamoorthy Subramanian (ramsubra)" We're implementing RFC4662 and wondering how to trigger full state notification. The spec says as follows. "Immediate notifications triggered as a result of subsequent SUBSCRIBE messages SHOULD include an RLMI document in which the full state is indicated. The RLS SHOULD also include state information for all resources in the list for which the RLS has state, subject to policy restrictions. This allows the subscriber to refresh their state, and to recover from lost notifications." [...] [Does] this means that the subscribe[r] should send another subscribe request (resubscribe) to get the full-state notification? Yes. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 23 22:56:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHtCO-0006UU-Gy; Wed, 23 Jan 2008 22:56:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHtCM-0006UJ-Uk for sip-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 22:56:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHtCM-0006UB-Jb for sip@ietf.org; Wed, 23 Jan 2008 22:56:18 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHtCM-0004mp-6B for sip@ietf.org; Wed, 23 Jan 2008 22:56:18 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 Jan 2008 19:56:17 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0O3uHml008819; Wed, 23 Jan 2008 19:56:17 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0O3uGj7004500; Thu, 24 Jan 2008 03:56:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 22:56:15 -0500 Received: from [10.82.217.233] ([10.82.217.233]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 22:56:15 -0500 Message-ID: <47980C64.2070801@cisco.com> Date: Wed, 23 Jan 2008 22:56:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] New version of draft-ietf-sip-body-handling-01.txt References: <47979565.2050700@ericsson.com> In-Reply-To: <47979565.2050700@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 03:56:15.0520 (UTC) FILETIME=[113BB200:01C85E3D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1734; t=1201146977; x=1202010977; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20New=20version=20of=20draft-ietf -sip-body-handling-01.txt |Sender:=20; bh=arOAE5DvWHDHdkn2PU2vxfjQp0S2lGPPO92U9mVM088=; b=KSKBAXNEwsokxzlo4NJr3JnNVuTiXrsEaGXzSZ90dqZe2pUigjrKGs4L6o tMNzRbTxmt9Sg5+2VD0jCp9+/U1NdZnDZ8V9+pjrUWDw6D5KWnmtVR38XQ/H 3uTpT90shU; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, This is *much* improved! (Not that it was bad before.) It is very straightforward and clear. I like it a lot. I was only thinking about one use case that may, or may not, warrant some special explanation - the use of sipfrag. A sipfrag is allowed to contain any subset of initial lines, headers, and body from a sip message. This could for instance lead to unsatisfied references to body parts, or to body parts that were intended to be referenced, but whose references have been elided. As a result it may not be possible to properly process the body parts of a sipfrag. I think this this is pretty much intended behavior and so it should be ok to send such ill-constructed things. But it might be good, here or somewhere else, to clarify the construction and usage of sipfrags - what makes sense and what does not. Thanks, Paul Gonzalo Camarillo wrote: > Folks, > > I have put together a new version of the body handling draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-01.txt > > This version addresses all the comments we got in its APPS review, which > included modifying the structure of the document. With respect to > references to body parts, per the guidelines we got from the APPS > people, the document now only allows forward references. > > Comments are welcome. > > Cheers, > > 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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 24 13:03:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6QA-0007Oj-HR; Thu, 24 Jan 2008 13:03:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JI6Q9-0007Oc-Ha for sip-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 13:03:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JI6Q9-0007OU-8B for sip@ietf.org; Thu, 24 Jan 2008 13:03:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6Oa-0007As-Ko for sip@ietf.org; Thu, 24 Jan 2008 13:01:48 -0500 Received: from fk-out-0910.google.com ([209.85.128.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI6OZ-0005zG-R4 for sip@ietf.org; Thu, 24 Jan 2008 13:01:48 -0500 Received: by fk-out-0910.google.com with SMTP id z23so295395fkz.5 for ; Thu, 24 Jan 2008 10:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=rFAP597c7RU8HItpTAwdjHWcUb4By0GlCmDmPL/qH8Y=; b=k7HY2v4I/3Mukr6gTuiK8gHnWWolGWhP47rHI4bMHqMd+ckO0LLEufTJH0JhCk1PiHTVxZNW2lSMHDvKfll/491f5cPmLjVV1r5wmNvuvNCdv8MCFvcgicdNZl6dP5ve0yDuv1Eb00kpRurSOb8MgpIpiwv3kUwL0wy1GdzU4Fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=gQZB1Sz2W0vnn5SelBzj6lV8HZ5/stee8Cud1KStC+8/55Kb2KuU344d37Fv1B1Dx04NC2KILFdtIQ3SwiRo4GK6l9SVeSWPGdvXSgKDiti2c817RrJ16aH6EovCP+G8I6XhYlKeI6k3XHznon7wUZd2h6B0I0FF4y3+wC12Sq8= Received: by 10.82.161.19 with SMTP id j19mr1750893bue.20.1201197706718; Thu, 24 Jan 2008 10:01:46 -0800 (PST) Received: by 10.82.190.13 with HTTP; Thu, 24 Jan 2008 10:01:46 -0800 (PST) Message-ID: Date: Thu, 24 Jan 2008 12:01:46 -0600 From: "David Roan" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-TMDA-Confirmed: Thu, 24 Jan 2008 13:03:25 -0500 Subject: [Sip] Target Refresh Request and Contact Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591239539==" Errors-To: sip-bounces@ietf.org --===============0591239539== Content-Type: multipart/alternative; boundary="----=_Part_2451_10828976.1201197706709" ------=_Part_2451_10828976.1201197706709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline According to RFC 3261, the following is stated in section 12.2.1.1: A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog. This seems to indicate that including the Contact header in a target refresh request (ie, Re-INVITE or UPDATE) is only a strong recommendation (ie, "SHOULD" vs "MUST"). However, table 3 in section 20 of RFC3261 seems to contradict this, as it lists the Contact header as "m": Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Contact R o - - m o o Also, table 1 in section 8 of RFC3311 lists the Contact header as "m" for the UPDATE request. Is there any consensus as to which is considered the correct statement? MUST the Contact header be included in target refresh requests(as indicated by the header tables in RFC3261 and RFC3311)? Or, SHOULD the Contact header be included in the target refresh request(as indicated by section 12.2.1.1 of RFC3261)? Thanks in advance for any input, insight, or clarification. John D. Roan ------=_Part_2451_10828976.1201197706709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
According to RFC 3261, the following is stated in section 12.2.1.1:
A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog.  If the "secure" flag is true, that URI MUST be a SIPS URI.As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI.  This allows a UA to provide a new contact address, should its address change during the duration of the dialog.
 
This seems to indicate that including the Contact header in a target refresh request (ie, Re-INVITE or UPDATE) is only a strong recommendation (ie, "SHOULD" vs "MUST").
 
However, table 3 in section 20 of RFC3261 seems to contradict this, as it lists the Contact header as "m":
Header field              where       proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Contact                      R                      o       -      -     m     o      o
 
Also, table 1 in section 8 of RFC3311 lists the Contact header as "m" for the UPDATE request.
 
Is there any consensus as to which is considered the correct statement? MUST the Contact header be included in target refresh requests(as indicated by the header tables in RFC3261 and RFC3311)? Or, SHOULD the Contact header be included in the target refresh request(as indicated by section 12.2.1.1 of RFC3261)?

Thanks in advance for any input, insight, or clarification.
John D. Roan
------=_Part_2451_10828976.1201197706709-- --===============0591239539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0591239539==-- From sip-bounces@ietf.org Thu Jan 24 13:11:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6YK-0003or-2t; Thu, 24 Jan 2008 13:11:52 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JI6YH-0003W4-Ki for sip-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 13:11:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6YH-0003UJ-7n for sip@ietf.org; Thu, 24 Jan 2008 13:11:49 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI6YG-0006HB-2h for sip@ietf.org; Thu, 24 Jan 2008 13:11:49 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2008 10:11:47 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0OIBljB024994; Thu, 24 Jan 2008 10:11:47 -0800 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0OIBk3V029735; Thu, 24 Jan 2008 18:11:47 GMT From: "Dan Wing" To: "'Fischer, Kai'" , References: <198A10EC585EC74687BCA414E2A5971801FD49B7@MCHP7RDA.ww002.siemens.net> Subject: RE: [Sip] End-to-end security for DTLS-SRTP (FW: I-DAction:draft-fischer-sip-e2e-sec-media-00.txt) Date: Thu, 24 Jan 2008 10:11:46 -0800 Message-ID: <009701c85eb4$9567a120$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchdoYOBj7k5YqdfRt26nwywkqFi4gAAD1sgAESeZiA= In-Reply-To: <198A10EC585EC74687BCA414E2A5971801FD49B7@MCHP7RDA.ww002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4774; t=1201198307; x=1202062307; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20End-to-end=20security=20for=20D TLS-SRTP=20(FW=3A=20I-DAction=3Adraft-fischer-sip-e2e-sec-me dia-00.txt) |Sender:=20; bh=UfMSVaMb2j4kiqld74DYALodji12vJMJU6W5pX9as/c=; b=iYdRWLBlSBEaAhnC8XTYzbJExMPdBj7q6gmzHTLr0/99KVK+fpSZXb2TW/ Tf/pcLRkX5hi/uUKf4rb3Q6bMMQpbrZVmw55aQi8mdGgVR/2xWxyH9E0AVx5 p7872wVqG7; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like this draft, and it solves a very real problem: providing identity for SIP requests that traverse B2BUAs and traverse SBCs. -d > -----Original Message----- > From: Fischer, Kai [mailto:kai.fischer@siemens.com] > Sent: Wednesday, January 23, 2008 1:34 AM > To: sip@ietf.org > Subject: [Sip] End-to-end security for DTLS-SRTP (FW: > I-DAction:draft-fischer-sip-e2e-sec-media-00.txt) > > Hi, > I have submitted a draft proposing a solution to secure a DTLS-SRTP > handshake and hence SRTP end-to-end (in terms of end-domain to > end-domain). As discussed during the last IETF meetings and > analyzed by > Dan's Identity-Media draft, current solutions like SIP Identity do not > protect the authenticity of the fingerprint end-to-end in certain > inter-domain scenarios. For example, a modification of SDP > m-/c-lines or > the From header field by intermediaries breaks the SIP-Identity or > Identity-Media signature and causes a re-signing by a domain different > to the originating one. The draft proposes a solution for > such scenarios > without the need to re-sign during domain traversal and which > preserves > the original identity information. > > I appreciate your comments and opinions to the draft and the proposed > solution. > > Kai > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Mittwoch, 23. Januar 2008 10:20 > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-fischer-sip-e2e-sec-media-00.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > Title : End-to-End Security for DTLS-SRTP > > Author(s) : K. Fischer > > Filename : draft-fischer-sip-e2e-sec-media-00.txt > > Pages : 14 > > Date : 2008-01-23 > > > > The end-to-end security properties of DTLS-SRTP depend on the > > authenticity of the certificate fingerprint exchanged in the > > signalling channel. In current approaches the authenticity is > > protected by SIP-Identity or SIP-Identity-Media. These types of > > signatures are broken if intermediaries like Session Border > > Controllers in other domains change specific information of the SIP > > header or the SIP body. The end-to-end security property > between the > > originating and terminating domain is lost if these intermediaries > > re-sign the SIP message and create a new identity signature using > > their own domain credentials. > > > > This document defines a new signature type 'Fingerprint-Identity' > > which is exchanged in the signalling channel. Fingerprint-Identity > > covers only those elements of a SIP message necessary to > authenticate > > the certificate fingerprint and to secure media end-to-end. It is > > independent from SIP-Identity and SIP-Identity-Media and can be > > applied in parallel to them. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-fischer-sip-e2e-sec- > > media-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-fischer-sip-e2e-sec-media-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-fischer-sip-e2e-sec-media-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 24 13:41:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI70i-000607-IR; Thu, 24 Jan 2008 13:41:12 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JI70h-0005ye-51 for sip-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 13:41:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI70g-0005xL-PX for sip@ietf.org; Thu, 24 Jan 2008 13:41:10 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI70g-0007EH-Cr for sip@ietf.org; Thu, 24 Jan 2008 13:41:10 -0500 X-IronPort-AV: E=Sophos;i="4.25,245,1199682000"; d="scan'208";a="84298878" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Jan 2008 13:41:11 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0OIfAAW020759; Thu, 24 Jan 2008 13:41:10 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0OIf1J9013926; Thu, 24 Jan 2008 18:41:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 13:41:08 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 13:41:08 -0500 Message-ID: <4798DBC9.70802@cisco.com> Date: Thu, 24 Jan 2008 13:41:13 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Roan Subject: Re: [Sip] Target Refresh Request and Contact Header References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 18:41:08.0472 (UTC) FILETIME=[AF193F80:01C85EB8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2207; t=1201200070; x=1202064070; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Target=20Refresh=20Request=20an d=20Contact=20Header |Sender:=20 |To:=20David=20Roan=20; bh=4fJMUgWAe9HfUmvAYJQkWSDTlHy0k6tVdEBahvnNE1g=; b=kJX2J6wBo730QMxZMvmLrQde3c/7UodkuqD9wXBXg50Wr8pvCi9LWeTfYV ovCLENNrU/Z+/neYI4Q8H4SRjZFU97whTvNA51Z1vEs4u238fzH6vCY5Api/ m52nuaPmBC; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org IMO it should be MUST. I suspect is is weaker for 2543 compatibility. Paul David Roan wrote: > According to RFC 3261, the following is stated in section 12.2.1.1 > : > A UAC SHOULD include a Contact header field in any target refresh > requests within a dialog, and unless there is a need to change it, the > URI SHOULD be the same as used in previous requests within the dialog. > If the "secure" flag is true, that URI MUST be a SIPS URI.As discussed > in Section 12.2.2, a Contact header field in a target refresh request > updates the remote target URI. This allows a UA to provide a new > contact address, should its address change during the duration of the > dialog. > > This seems to indicate that including the Contact header in a target > refresh request (ie, Re-INVITE or UPDATE) is only a strong > recommendation (ie, "SHOULD" vs "MUST"). > > However, table 3 in section 20 of RFC3261 seems to contradict this, as > it lists the Contact header as "m": > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________________ > Contact R o - - > m o o > > Also, table 1 in section 8 of RFC3311 lists the Contact header as "m" > for the UPDATE request. > > Is there any consensus as to which is considered the correct statement? > MUST the Contact header be included in target refresh requests(as > indicated by the header tables in RFC3261 and RFC3311)? Or, SHOULD the > Contact header be included in the target refresh request(as indicated by > section 12.2.1.1 of RFC3261)? > > Thanks in advance for any input, insight, or clarification. > John D. Roan > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 24 15:15:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8Tw-00072C-Mm; Thu, 24 Jan 2008 15:15:28 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JI8Tv-000726-9a for sip-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 15:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8Tu-00071y-Vv for sip@ietf.org; Thu, 24 Jan 2008 15:15:26 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI8Tu-00088b-9U for sip@ietf.org; Thu, 24 Jan 2008 15:15:26 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AC967207E8; Thu, 24 Jan 2008 21:15:25 +0100 (CET) X-AuditID: c1b4fb3c-abaefbb0000007e0-5f-4798f1ddbd67 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8DF3D20679; Thu, 24 Jan 2008 21:15:25 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 21:15:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Target Refresh Request and Contact Header Date: Thu, 24 Jan 2008 21:15:24 +0100 Message-ID: In-Reply-To: <4798DBC9.70802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Target Refresh Request and Contact Header thread-index: AcheuLaR8sEbSdwnQtC3iTii94iZxwADP80A References: <4798DBC9.70802@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "David Roan" X-OriginalArrivalTime: 24 Jan 2008 20:15:25.0261 (UTC) FILETIME=[DACEBFD0:01C85EC5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Is there something that could go wrong if it is not included? Regards, Christer=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 24. tammikuuta 2008 20:41 > To: David Roan > Cc: sip@ietf.org > Subject: Re: [Sip] Target Refresh Request and Contact Header >=20 > IMO it should be MUST. I suspect is is weaker for 2543 compatibility. >=20 > Paul >=20 > David Roan wrote: > > According to RFC 3261, the following is stated in section 12.2.1.1 > > : > > A UAC SHOULD include a Contact header field in any target refresh=20 > > requests within a dialog, and unless there is a need to=20 > change it, the=20 > > URI SHOULD be the same as used in previous requests within=20 > the dialog. > > If the "secure" flag is true, that URI MUST be a SIPS=20 > URI.As discussed=20 > > in Section 12.2.2, a Contact header field in a target=20 > refresh request=20 > > updates the remote target URI. This allows a UA to provide a new=20 > > contact address, should its address change during the=20 > duration of the=20 > > dialog. > > =20 > > This seems to indicate that including the Contact header in=20 > a target=20 > > refresh request (ie, Re-INVITE or UPDATE) is only a strong=20 > > recommendation (ie, "SHOULD" vs "MUST"). > > =20 > > However, table 3 in section 20 of RFC3261 seems to=20 > contradict this, as=20 > > it lists the Contact header as "m": > > Header field where proxy ACK BYE CAN INV OPT REG > > ___________________________________________________________________ > > Contact R o =20 > - - =20 > > m o o > > =20 > > Also, table 1 in section 8 of RFC3311 lists the Contact=20 > header as "m"=20 > > for the UPDATE request. > > =20 > > Is there any consensus as to which is considered the=20 > correct statement?=20 > > MUST the Contact header be included in target refresh requests(as=20 > > indicated by the header tables in RFC3261 and RFC3311)? Or,=20 > SHOULD the=20 > > Contact header be included in the target refresh request(as=20 > indicated=20 > > by section 12.2.1.1 of RFC3261)? > >=20 > > Thanks in advance for any input, insight, or clarification. > > John D. Roan > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 24 15:23:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8bn-0002rk-0R; Thu, 24 Jan 2008 15:23:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JI8bl-0002fL-29 for sip-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 15:23:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8bk-0002dE-Ne for sip@ietf.org; Thu, 24 Jan 2008 15:23:32 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI8bk-0008JJ-4E for sip@ietf.org; Thu, 24 Jan 2008 15:23:32 -0500 X-IronPort-AV: E=Sophos;i="4.25,246,1199682000"; d="scan'208";a="84311524" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Jan 2008 15:22:52 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0OKMp58012304; Thu, 24 Jan 2008 15:22:51 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0OKMpVP028918; Thu, 24 Jan 2008 20:22:51 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 15:22:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Target Refresh Request and Contact Header Date: Thu, 24 Jan 2008 15:22:20 -0500 Message-ID: <5C5630E45267B642894988A97570D32215459E@xmb-rtp-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Target Refresh Request and Contact Header Thread-Index: AcheuLaR8sEbSdwnQtC3iTii94iZxwADP80AAAA/aeA= From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Paul Kyzivat (pkyzivat)" , "David Roan" X-OriginalArrivalTime: 24 Jan 2008 20:22:48.0471 (UTC) FILETIME=[E2FB3A70:01C85EC6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3872; t=1201206171; x=1202070171; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Target=20Refresh=20Request=20an d=20Contact=20Header |Sender:=20 |To:=20=22Christer=20Holmberg=22=20,=0A=20=20=20=20=20=20=20=20=22Paul=20Kyzivat=20(pky zivat)=22=20,=0A=20=20=20=20=20=20=20=20 =22David=20Roan=22=20; bh=2pBbJZMe/FOl5kJfHwNm4dASCKEvzw+8ondqkF2fNTs=; b=DG2yNqb3cABeL1LH9UeJh00w+QaVCpw86V8ctKdFZzjE1wN/fjFydOKiqN Ur8aYR7NrdANg94XtwmbokKW8Oya8RWlWMEjOw68q1HHQV9FF/OwITkX/Yc6 cXK40dRhuU; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess most 3261 compliant implementations will send a 400 error response. 2543 compliant spec, most likely, will accept it. Sanjay=20 >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 >Sent: Thursday, January 24, 2008 3:15 PM >To: Paul Kyzivat (pkyzivat); David Roan >Cc: sip@ietf.org >Subject: RE: [Sip] Target Refresh Request and Contact Header > > >Hi, > >Is there something that could go wrong if it is not included? > >Regards, > >Christer=20 > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 24. tammikuuta 2008 20:41 >> To: David Roan >> Cc: sip@ietf.org >> Subject: Re: [Sip] Target Refresh Request and Contact Header >>=20 >> IMO it should be MUST. I suspect is is weaker for 2543 compatibility. >>=20 >> Paul >>=20 >> David Roan wrote: >> > According to RFC 3261, the following is stated in section 12.2.1.1 >> > : >> > A UAC SHOULD include a Contact header field in any target refresh=20 >> > requests within a dialog, and unless there is a need to >> change it, the >> > URI SHOULD be the same as used in previous requests within >> the dialog. >> > If the "secure" flag is true, that URI MUST be a SIPS >> URI.As discussed >> > in Section 12.2.2, a Contact header field in a target >> refresh request >> > updates the remote target URI. This allows a UA to provide a new=20 >> > contact address, should its address change during the >> duration of the >> > dialog. >> > =20 >> > This seems to indicate that including the Contact header in >> a target >> > refresh request (ie, Re-INVITE or UPDATE) is only a strong=20 >> > recommendation (ie, "SHOULD" vs "MUST"). >> > =20 >> > However, table 3 in section 20 of RFC3261 seems to >> contradict this, as >> > it lists the Contact header as "m": >> > Header field where proxy ACK BYE CAN INV OPT REG >> > ___________________________________________________________________ >> > Contact R o =20 >> - - =20 >> > m o o >> > =20 >> > Also, table 1 in section 8 of RFC3311 lists the Contact >> header as "m"=20 >> > for the UPDATE request. >> > =20 >> > Is there any consensus as to which is considered the >> correct statement?=20 >> > MUST the Contact header be included in target refresh requests(as=20 >> > indicated by the header tables in RFC3261 and RFC3311)? Or, >> SHOULD the >> > Contact header be included in the target refresh request(as >> indicated >> > by section 12.2.1.1 of RFC3261)? >> >=20 >> > Thanks in advance for any input, insight, or clarification. >> > John D. Roan >> >=20 >> >=20 >> >=20 >>=20 >---------------------------------------------------------------------- >> > -- >> >=20 >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol Use=20 >> > sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> > sipping@ietf.org for new developments on the application of sip >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >>=20 > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 25 15:49:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVUZ-000647-Al; Fri, 25 Jan 2008 15:49:39 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JIVUY-00062j-31 for sip-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 15:49:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVUX-00061b-NS for sip@ietf.org; Fri, 25 Jan 2008 15:49:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIVUV-0004bC-Vl for sip@ietf.org; Fri, 25 Jan 2008 15:49:37 -0500 X-IronPort-AV: E=Sophos;i="4.25,252,1199692800"; d="scan'208";a="9837422" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2008 12:49:35 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0PKnZXY024665; Fri, 25 Jan 2008 12:49:35 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0PKnL3h029131; Fri, 25 Jan 2008 20:49:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:49:33 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:49:33 -0800 Message-ID: <479A4B4D.2090905@cisco.com> Date: Fri, 25 Jan 2008 15:49:17 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net> A <"C A9998CD 4A02 0D41 8654FCDEF4E7 07DF04173AE9"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2008 20:49:33.0284 (UTC) FILETIME=[C9F00240:01C85F93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9265; t=1201294175; x=1202158175; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Delivering=20request-UR I=20and=20parameters=20to=20UAS=20via=20proxy=0A=20-new=20ve rsion=20of=20the=20draft-holmberg-sip-target-uri-delivery=20 draft |Sender:=20; bh=DqxbGjoqZoPizHnCfJAILKQ9gb1XmiKlSjDs2POQAcI=; b=WvgLWWra/k9s4hrnHfbWNX1U6imI4No4v11x3xt6mfGm/SkhWu+lYj8M/T 2pqonPHMABbBvO2UvjbByUqO4yaGhKzicRLXCo7UQMdXwXW8twb3M9cSlV7Q 2IcdZ2i+vKI1wIK5i1X1GaAAIdjLr/B7bSaNqRTUbpB0N2XYgwwS4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet , Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for jumping in late here. Trying to clarify some points here and there. The UA-loose mechanism needs to know that the entity which would have previously been reached by the DNS/IP forwarding based on the R-URI, is now prepared for a request which reaches it with that target in the Route header field. In the case of a UA registering through a chain of Path-inserting proxies, it means that only the *UA* has to support UA-loose route. Thats because of the assumption that the intermediate path-inserting proxies weren't being targeted based on the R-URI previously; they were (and still will) forward the request based on Route. The 'next hop' use case that Christer is referring to are cases where we would have done a R-URI translation without a registration. For example, lets say a proxy receives an INVITE with sip:12345@proxy.com, and its using some number-prefix based routing rules, which have been CONFIGURED into the proxy, to determine a next-hop gateway. The UA loose route rules would say that, since this is a routing operation and not a retargeting, the request looks like: INVITE sip:12345@proxy.com Route: sip:ip-of-gateway whereas current rules would require: INVITE sip:12345@ip-of-gateway in this use case, the entity which was previously being reached by the R-URI *is* the next hop. And so, the main limitation that I see of the UA loose route mechanism is, in cases where the next-hop is being reached via a configured routing rule, or by some other non-registration means, and said operation is a re-route and not retarget, the UA_loose-route requires that this configured routing rule include information about whether the next hop uses UA loose routing, and if so, what URI to use in the Route header. This is a limitation, I agree. Whether its significant or not is debatable. I will note that, it is possible to separate these concerns. We could define UA loose route to strictly be used for the registration cases, since that is the specific problem at hand. I agree CHrister's mechanism does not have this configuration limitation, and that this aspect of it is better. My main beef, as others have commented, is that it leaves us with nearly half-dozen header fields which are all awfully similar (To, P-C-ID, Route, History-Info, and now Target). I was hoping to reduce the set and include only the minimum. In that way, I think UA loose route is architecturally better since it gives some clarity to this. -Jonathan R. Elwell, John wrote: > Christer, > > I don't think the entity using the mechanism needs to know about next > hop support for the loose route mechanism - only whether the UAS > supports it. If the UA registers, then the loose route draft provides an > automatic mechanism. If the UA does not register, support would need to > be indicated by provisioning. I am not sure this ranks as a significant > limitation, since a certain amount of provisioning needs to be done > anyway for UAs such as gateways that do not register. > > John > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 16 January 2008 11:51 >> To: Elwell, John; sip@ietf.org >> Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet >> Subject: RE: [Sip] RE: Delivering request-URI and parameters >> to UAS via proxy -new version of the >> draft-holmberg-sip-target-uri-delivery draft >> >> >> Hi, >> >>> I hear what you are saying, but I don't really see that the >> points you >> raised in section 4 are real limitations of the loose route mechanism. >> >> I think it is a limitation that an entity using the mechanism has to >> know whether the the next hop supports it or not, and that >> the mechanism >> can only be used if the subsequent hops support it. >> >> Regards, >> >> Christer >> >> >> >> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: 16 January 2008 11:06 >>>> To: Elwell, John; sip@ietf.org >>>> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet >>>> Subject: [Sip] RE: Delivering request-URI and parameters >> to UAS via >>>> proxy - new version of the draft-holmberg-sip-target-uri-delivery >>>> draft >>>> >>>> >>>> Hi John, >>>> >>>>> Thanks for this revision, which makes things somewhat >>> clearer. I do >>>>> have a couple of comments: >>>>> >>>>> 1. I am not sure I agree with the assertions in section 4 >>> concerning >>>>> issues with the mechanisms in loose-route. Taking example 1, the >>>>> Route header field should contain enough entries to get >> you to the >>>>> registered contact, not just to an intermediate proxy. >>> Therefore this >>>>> situation should not arise with a correctly implemented >>> home proxy. >>>>> It is not clear to me how example 2 could arise either, >>> for similar >>>>> reasons. The MGC case can be resolved by taking into account the >>>>> option tag in the REGISTER request, or if it is permanently >>>>> registered, through provisioning. >>>> The examples are not meant to show bugs in the loose-route >>> mechanism. >>>> They are meant to help people understand the limitations with the >>>> loose-route mechanism. >>>> >>>>> 2. Comparing the mechanism proposed with the loose-route >>> mechanism, >>>>> my understanding is: >>>>> a)When retargeting occurs, the loose-route mechanism >>> places the new >>>>> target in the Request URI. Your proposal places the new >> target in >>>>> both the Request-URI and the Target header field. >>>>> b) When rerouting, the loose-route mechanism places the >> new route >>>>> (i.e., the registered contact) in the Route header field. Your >>>>> proposal places the new route in the Request-URI (the >>> latter as per >>>>> RFC 3261). >>>>> So the two mechanisms solve exactly the same problems using a >>>>> slightly different mechanism. Correct? >>>> Yes. The two solutions intend to solve the same problem. >>>> >>>>> 3. How P-Called-Party-ID fits into this is not really >>> relevant from >>>>> an IETF perspective - it seems there are some 3GPP-specific >>>>> situations where the contents of P-Called-Party-ID will >>> not equal the >>>>> contents of Target. Correct? >>>> Correct. >>>> >>>>> 4. If my suggestion in point 1 above that the loose-route >>> mechanism >>>>> does not suffer from the problems suggested, then each >>> mechanism will >>>>> work and each addresses the same problem. >>>>> So it is just down to a beauty contest between the two. Correct? >>>> See question 1. >>>> >>>> We believe that our solution does not have the same >>> limitations as the >>>> loose-route solution. But, again, both solutions intend to >>> solve the >>>> same problem. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: Christer Holmberg >> [mailto:christer.holmberg@ericsson.com] >>>>>> Sent: 16 January 2008 08:41 >>>>>> To: sip@ietf.org >>>>>> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; >>> Jeroen van >>>>>> Bemmel; Francois Audet >>>>>> Subject: Delivering request-URI and parameters to UAS via >>>>> proxy - new >>>>>> version of the draft-holmberg-sip-target-uri-delivery draft >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> We've uploaded a new version (-01) of the Target draft. >>>>>> >>>>>> We've tried to make things more clear. I've also >>> removed all text >>>>>> about P-Called-Party-ID, except from one chapter where >>> we try to >>>>>> explain the semantical difference between Target and P-CPI. >>>>>> >>>>>> You can also find the draft from: >>>>>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ >>>>>> et-uri-del >>>>>> ivery-01.txt >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@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@cs.columbia.edu for questions on current sip >>> Use sipping@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@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jan 25 15:56:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVbF-0008Ne-It; Fri, 25 Jan 2008 15:56:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JIVbE-0008Lg-9X for sip-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 15:56:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVbD-0008LY-W8 for sip@ietf.org; Fri, 25 Jan 2008 15:56:31 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIVbC-0004jZ-8C for sip@ietf.org; Fri, 25 Jan 2008 15:56:31 -0500 X-IronPort-AV: E=Sophos;i="4.25,252,1199692800"; d="scan'208";a="4205212" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2008 12:56:29 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0PKuTjw002167 for ; Fri, 25 Jan 2008 12:56:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0PKu8jb015102 for ; Fri, 25 Jan 2008 20:56:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:56:11 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 12:56:10 -0800 Message-ID: <479A4CDB.4040403@cisco.com> Date: Fri, 25 Jan 2008 15:55:55 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2008 20:56:10.0925 (UTC) FILETIME=[B6F335D0:01C85F94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=510; t=1201294589; x=1202158589; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20UA=20loose=20route=20resubmitted |Sender:=20; bh=sHg5NbItFG8pXlHv8WmNTOMkIWdxQnVQcz4a28mcoJ8=; b=hauk5gE3hAJgL5QazpwQvsU6x7MDEuxyA8Q/7KaorBCPC2bB+cdqaAV2RW jcBc3qrPfxsXIIlU6AEwWNRcgcA9ERsTdThO06ieAcgNcAKutvuC68g+H37S KEoQerHLHqxJODnHl72s9UQEL4lYYuh26xUIECllm8kja2KWQR0BQ=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] UA loose route resubmitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-02.txt I didn't change anything since -01; but -01 had expired. Since we are discussing it it made sense to have a version in the archives. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 28 10:58:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWNd-0003QT-10; Mon, 28 Jan 2008 10:58:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJWNb-0003QO-S9 for sip-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 10:58:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWNb-0003QG-IS for sip@ietf.org; Mon, 28 Jan 2008 10:58:39 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWNZ-00036Y-Lj for sip@ietf.org; Mon, 28 Jan 2008 10:58:39 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 16:58:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Mon, 28 Jan 2008 16:57:39 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE06990C59@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-Index: AchWzqJNXVX4sjNuQSaW1d5oVZlILgKRsZpg From: To: , X-OriginalArrivalTime: 28 Jan 2008 15:58:23.0505 (UTC) FILETIME=[9C608810:01C861C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 There are other cases similar to what is described in section 2.1 = Unknown Aliases of J. Rosenberg draft that should be taken into account. = Those cases are where the customer side is composed of several SIP = terminals that access the network through an intermediate entity which = registers their associated aliases with its contact address. Thus, such = client side is seen from the network as a single client having several = aliases (aggregated endpoints). Moreover, such client side may be a mini = private network composed of several entities. In these configurations, = the intermediate entity is in charge of routeing incoming calls inside = the client domain and may need to behave as a SIP proxy for incoming SIP = messages. =20 As examples of such configuration: - Corporate networks: in that case the PBX register all the served = individual user identities with its contact address and routes incoming = calls toward the individual called users. - Home networks: the Home Gateway may need to register on behalf of all = the served terminals. The Home Gateway is in charge of routeing = incoming calls toward the individual called users.=20 J. Rosenberg draft seems give a good solution to take into account these = configurations. =20 Best regards, Youssef > -----Message d'origine----- > De : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Envoy=E9 : lundi 14 janvier 2008 17:58 > =C0 : sip@ietf.org > Objet : [Sip] Delivering request-URI and parameters to UAS via proxy >=20 > (As WG chair) >=20 > In fulfilment of our charter items of >=20 > Dec 2007 Delivering request-URI and parameters to UAS via proxy to > WGLC =20 > Feb 2008 Delivering request-URI and parameters to UAS via proxy to > IESG (PS) >=20 > We now have a couple of proposals on the table for solving=20 > the problem. >=20 > The original draft from Jonathan and which led to the=20 > creation of the charter items by the WG is unfortunately=20 > expired, but is at: >=20 > http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt >=20 > The alternative document from Christer, etc is at: >=20 > http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- > uri-delive > ry-00.txt >=20 > We obviously need to make a decision between the two=20 > approaches so please attempt to address the following=20 > specific points via the mailing > list: >=20 > 1) Problem cases: These are summarised in section 4.4 of > draft-rosenberg-sip-ua-loose-route-01 and from my read of the=20 > other draft, I don't believe that this draft adds any others.=20 > If you believe there are other cases that should be covered=20 > by the solution, then please identify them. If there is=20 > support on any new problem cases, I would encourage the=20 > authors of both drafts to add text concerning these problem cases. >=20 > 2) Clarifications: If for any reason you don't understand either > draft, or believe that there are technical issues that are=20 > not represented in the current draft, please post your=20 > questions / comments to the list. I would encourage authors=20 > of both drafts to revise as frequently as appropriate to=20 > reflect the current state of discussion. >=20 > 3) Support for either position. If you wish to indicate support for > either position please do so, but please accompany this is=20 > technical reasoning as to why you have this position, as that=20 > will help other members of the WG form a position. >=20 > I would encourage as much list discussion as possible before=20 > Philadelphia. I suspect we will need to have a discussion at=20 > the face-to-face meeting in Philadephia, but list discussion=20 > is essential prior to that. If we can solve this positions on=20 > list, then well and good, and even better (that is how we are=20 > meant to make decisions). >=20 > Regards >=20 >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 28 15:46:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJarZ-00050E-Hz; Mon, 28 Jan 2008 15:45:53 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJarX-000509-U2 for sip-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 15:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJarX-0004zz-KB for sip@ietf.org; Mon, 28 Jan 2008 15:45:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJarW-0003Qp-Ov for sip@ietf.org; Mon, 28 Jan 2008 15:45:51 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jan 2008 15:45:51 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0SKjo0V031204; Mon, 28 Jan 2008 15:45:50 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0SKjNJb019057; Mon, 28 Jan 2008 20:45:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 15:45:41 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 15:45:40 -0500 Message-ID: <479E3EF9.1080109@cisco.com> Date: Mon, 28 Jan 2008 15:45:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: youssef.chadli@orange-ftgroup.com Subject: Re: [Sip] Delivering request-URI and parameters to UAS via proxy References: <2AF8FF7D89242541B12E7A47F6ECB4BE06990C59@ftrdmel3> In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE06990C59@ftrdmel3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Jan 2008 20:45:40.0580 (UTC) FILETIME=[BE797240:01C861EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5018; t=1201553150; x=1202417150; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Delivering=20request-URI=20and= 20parameters=20to=20UAS=20via=20proxy |Sender:=20 |To:=20youssef.chadli@orange-ftgroup.com; bh=qNkEVJv0he1skCMXINeWgSkAECs9FDD2/5O5TbAqiYw=; b=vx6n4tVg2osd7kIvkq5gZTjReoKBprSFlv/hl6JtFSuxjgx51W21SbiSHS Cv44BFQ6D/85KPPhq9YHzidT5fq6vhn/zDtPnvOm9fNEVe/BTu++EYeygEfw CQ8yHy9K31; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org, drage@alcatel-lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org These cases can all be handled by having intermediate entity use a unique user part, together with its own domain name, to construct a contact address for each terminal UA that it is registering. Then when it receives an incoming request to one of these uris it can simply translate it, using the user part as a key to its own local mappings. We don't need anything new to solve these cases. Paul youssef.chadli@orange-ftgroup.com wrote: > > There are other cases similar to what is described in section 2.1 Unknown Aliases of J. Rosenberg draft that should be taken into account. > > Those cases are where the customer side is composed of several SIP terminals that access the network through an intermediate entity which registers their associated aliases with its contact address. Thus, such client side is seen from the network as a single client having several aliases (aggregated endpoints). Moreover, such client side may be a mini private network composed of several entities. In these configurations, the intermediate entity is in charge of routeing incoming calls inside the client domain and may need to behave as a SIP proxy for incoming SIP messages. > > As examples of such configuration: > - Corporate networks: in that case the PBX register all the served individual user identities with its contact address and routes incoming calls toward the individual called users. > - Home networks: the Home Gateway may need to register on behalf of all the served terminals. The Home Gateway is in charge of routeing incoming calls toward the individual called users. > > J. Rosenberg draft seems give a good solution to take into account these configurations. > > Best regards, > > Youssef > > >> -----Message d'origine----- >> De : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> Envoyé : lundi 14 janvier 2008 17:58 >> À : sip@ietf.org >> Objet : [Sip] Delivering request-URI and parameters to UAS via proxy >> >> (As WG chair) >> >> In fulfilment of our charter items of >> >> Dec 2007 Delivering request-URI and parameters to UAS via proxy to >> WGLC >> Feb 2008 Delivering request-URI and parameters to UAS via proxy to >> IESG (PS) >> >> We now have a couple of proposals on the table for solving >> the problem. >> >> The original draft from Jonathan and which led to the >> creation of the charter items by the WG is unfortunately >> expired, but is at: >> >> http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt >> >> The alternative document from Christer, etc is at: >> >> http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- >> uri-delive >> ry-00.txt >> >> We obviously need to make a decision between the two >> approaches so please attempt to address the following >> specific points via the mailing >> list: >> >> 1) Problem cases: These are summarised in section 4.4 of >> draft-rosenberg-sip-ua-loose-route-01 and from my read of the >> other draft, I don't believe that this draft adds any others. >> If you believe there are other cases that should be covered >> by the solution, then please identify them. If there is >> support on any new problem cases, I would encourage the >> authors of both drafts to add text concerning these problem cases. >> >> 2) Clarifications: If for any reason you don't understand either >> draft, or believe that there are technical issues that are >> not represented in the current draft, please post your >> questions / comments to the list. I would encourage authors >> of both drafts to revise as frequently as appropriate to >> reflect the current state of discussion. >> >> 3) Support for either position. If you wish to indicate support for >> either position please do so, but please accompany this is >> technical reasoning as to why you have this position, as that >> will help other members of the WG form a position. >> >> I would encourage as much list discussion as possible before >> Philadelphia. I suspect we will need to have a discussion at >> the face-to-face meeting in Philadephia, but list discussion >> is essential prior to that. If we can solve this positions on >> list, then well and good, and even better (that is how we are >> meant to make decisions). >> >> Regards >> >> >> Keith >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 28 16:06:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbBC-0005SH-VI; Mon, 28 Jan 2008 16:06:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJVf4-0007rf-Kl for sip-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 10:12:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJVf4-0007qS-A2 for sip@ietf.org; Mon, 28 Jan 2008 10:12:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJVdS-0005yR-8L for sip@ietf.org; Mon, 28 Jan 2008 10:10:58 -0500 Received: from web55709.mail.re3.yahoo.com ([216.252.110.40]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJVdR-0006Jb-QF for sip@ietf.org; Mon, 28 Jan 2008 10:10:58 -0500 Received: (qmail 21639 invoked by uid 60001); 28 Jan 2008 15:10:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nz5BD/ukQBPaPLQ5nkXJGblh8JEkKCPAwxpr2x7guA1EX3W9973IhAb4YGwTd6mo4NSlABgnUbd94fjzRNWbVbZ9cl4dX4qPQowCbwmaUDSOpMJiEx3IO4SRUaS9t6OW4r0FiA7BRtB8KcX7yi49AayWWupVJ/hJRoPTS5eVrkQ=; X-YMail-OSG: CiI9VUUVM1m2I5boCepyUi77rtwRBhfuY9Po84O1S_ITHmkmuWvFn3RLTWJIMrv_bFyrpszUqksY5ZPm.TP9UNu3WZZ6jutlqyhxWSSQcDAddc2gyekaaZ4DpfWXtJ36EFauHKcRCXUl_J0- Received: from [212.34.2.172] by web55709.mail.re3.yahoo.com via HTTP; Mon, 28 Jan 2008 07:10:56 PST Date: Mon, 28 Jan 2008 07:10:56 -0800 (PST) From: HOSSAM ALDEBEI To: sip@ietf.org, jiri@iptel.org, rshiroor@aplion.stpn.soft.net MIME-Version: 1.0 Message-ID: <709921.15455.qm@web55709.mail.re3.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-TMDA-Confirmed: Mon, 28 Jan 2008 10:12:38 -0500 X-Mailman-Approved-At: Mon, 28 Jan 2008 16:06:09 -0500 Cc: Subject: [Sip] SIP ack Method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1175695255==" Errors-To: sip-bounces@ietf.org --===============1175695255== Content-Type: multipart/alternative; boundary="0-893904885-1201533056=:15455" Content-Transfer-Encoding: 8bit --0-893904885-1201533056=:15455 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dears this is hossam from jordan when the SAU server (A) send an invite message to CommuniGate PBX (B) , the call occured with nothing heared from the PBX IVR system, after checking the Sip call flow on the trace we found that the last Ack after the 200 ok message sent in the "TO" field instead of "CONTACT" field as appeared which is not the same as that in RFC 3261, how can we solve this issue and force the CommuniGate to accept the ACK message . hope to hear from you many thanx --------------------------------- Never miss a thing. Make Yahoo your homepage. --0-893904885-1201533056=:15455 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dears
 
this is hossam from jordan
 
when the SAU server (A) send an invite message to CommuniGate PBX (B) , the call occured with nothing heared from the PBX IVR system, after checking the Sip call flow on the trace we found that the last Ack after the 200 ok message sent in the "TO" field instead of "CONTACT" field as appeared which is not the same as that in RFC 3261, how can we solve this issue and force the CommuniGate to accept the ACK message .

hope to hear from you
 
many thanx

Never miss a thing. Make Yahoo your homepage. --0-893904885-1201533056=:15455-- --===============1175695255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1175695255==-- From sip-bounces@ietf.org Mon Jan 28 16:12:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbGp-0005dQ-Bx; Mon, 28 Jan 2008 16:11:59 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHvwd-00070Y-N2 for sip-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 01:52:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JHvwd-00070O-DB for sip@ietf.org; Thu, 24 Jan 2008 01:52:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHuvP-0007XW-Mx for sip@ietf.org; Thu, 24 Jan 2008 00:46:55 -0500 Received: from an-out-0708.google.com ([209.85.132.247]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHuvP-00079q-Aw for sip@ietf.org; Thu, 24 Jan 2008 00:46:55 -0500 Received: by an-out-0708.google.com with SMTP id d11so44756and.122 for ; Wed, 23 Jan 2008 21:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=NQLbHsiIM473KrIBlEfQa19P45NRDj4rtZ1U85HtrV8=; b=c5fZSx5Nwd+g3dQQmX3fWPhYQkhoMdp3f0iukOmv98dEmfNh6DgzR3kWKGoWEGM8ClvC9aoRCEC9Jt3cvx426K0qsXXG0TS2rJ3Bom7NW6doJO0uLRyodxmJlt2z9zA5U8ai8uzos61/LObtS8hR7MDYg2gGlltOCjMIjhKj3eA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=xoojGA9S/Y+96GN3uq6UzapMTnHHBZkY74qrBL4XTyW/pC33AN/IJ5uYspP0UPKLEan+4q3O/VWaV1iGDRi6BVK+/ml2RuPTIHpU7fRKOgO3uLcGl9OS5Gd5/Lqk3udcOeAWF2CRfj/GVjlmPeSj+ukZtysnSDsi4NZf8acrzfM= Received: by 10.100.216.3 with SMTP id o3mr596827ang.28.1201153614995; Wed, 23 Jan 2008 21:46:54 -0800 (PST) Received: by 10.100.9.5 with HTTP; Wed, 23 Jan 2008 21:46:54 -0800 (PST) Message-ID: <24e80f870801232146v69f42461sbcdeef6787f4ae3b@mail.gmail.com> Date: Thu, 24 Jan 2008 11:16:54 +0530 From: "suryakanta mandal" To: sip@ietf.org, Sip-implementors@lists.cs.columbia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-TMDA-Confirmed: Thu, 24 Jan 2008 01:52:15 -0500 X-Mailman-Approved-At: Mon, 28 Jan 2008 16:11:57 -0500 Cc: Subject: [Sip] Contradictory Semantics header againest Join header in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have a query about the contradictory semantics header againest Join header. In RFC 3911 it's saying the following "The Join header has specific call control semantics. If both a Join header field and another header field with contradictory semantics (for example a Replaces [8] header field) are present in a request, the request MUST be rejected with a 400 "Bad Request" response. " here it specifies that Replace is the one Contradictory header for join but I seek to know that who else header has the contradictory semantics againest Join header for an INVITE _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 28 16:12:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbHA-00064Y-NZ; Mon, 28 Jan 2008 16:12:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JIMt7-0008M9-NK for sip-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:38:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMt7-0008Jo-AD for sip@ietf.org; Fri, 25 Jan 2008 06:38:25 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIMt6-0002gG-Ua for sip@ietf.org; Fri, 25 Jan 2008 06:38:25 -0500 Received: by an-out-0708.google.com with SMTP id d11so263660and.122 for ; Fri, 25 Jan 2008 03:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=cJdL7PdW9lA5W+6HkYIqEy+0Rw3QehlK7dW8FqFD6xA=; b=IzAJZcb+TFAbRG5MmjWJEwAggZKBW4K32fzMFYQ/Iwcqx0Z7oZFS4L728yTkP6f/QT3s9DkHn/jax0xwPZuaD51fU+t9dN0bh3SQKpjtoQcWi/DHaHdHj9uAP7ZkgUSaejeKtOU8wOeyuWSPrDWvsrD+l/nZvVwdkeNVnXgEEH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=RZinQ/toYA95BjUoagG0jT9AuEC9g0mERcgArkBCUF6UR7PGCcQR673Xak54ilcAH32PoEysdDXlaQ5bQ+Gk8auHC1DxU4rXd1MxZ+ICGMzN56oY+utjVcfXKu7EzjYC1/XuQ+xbJ/Wd2C4vR+L6XjhGqnD7ZRp87i7rHJorLHQ= Received: by 10.100.112.6 with SMTP id k6mr3918462anc.110.1201261104591; Fri, 25 Jan 2008 03:38:24 -0800 (PST) Received: by 10.100.9.5 with HTTP; Fri, 25 Jan 2008 03:38:24 -0800 (PST) Message-ID: <24e80f870801250338w7df91a20s26d78a61cfd619aa@mail.gmail.com> Date: Fri, 25 Jan 2008 17:08:24 +0530 From: "suryakanta mandal" To: sip-implementors-request@lists.cs.columbia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Mon, 28 Jan 2008 16:12:19 -0500 Cc: sip@ietf.org Subject: [Sip] 180 for PRACK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi , If you look at the RFC 3262, it says in Section 4: UAC behaviour Header field where PRACK ___________________________________ Alert-Info 180 - Contact 1xx - Contact 3xx o Error-Info 300-699 o Record-Route 2xx,18x o and If you look at the functionality of these column from RFC 3261 "The "where" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the "where" column indicates that the header field may be present in all requests and responses. The "proxy" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The next six columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. *: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. " I got struck on these above points. Can you let me know the scenario when the UAS will generate 180 for PRACK ? and when UAS will generate 3xx response for PRACK because their it mentioned optional means UAS may or may not generate 3xx response. Surya Aricent _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jan 28 16:40:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbiI-0002hJ-0J; Mon, 28 Jan 2008 16:40:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJbiG-0002h0-D0 for sip-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 16:40:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbiG-0002fo-2T for sip@ietf.org; Mon, 28 Jan 2008 16:40:20 -0500 Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJbiF-0004p2-JZ for sip@ietf.org; Mon, 28 Jan 2008 16:40:19 -0500 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ikqA1Y0090mlR8U0A06W00; Mon, 28 Jan 2008 21:40:18 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id ilgG1Y00M0umElk8X00000; Mon, 28 Jan 2008 21:40:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=CiAGlkhuxDBBKdmVe6EA:9 a=wU8rrqkbkDehLu7euR0_6QjY5oYA:4 a=rC2wZJ5BpNYA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m0SLeG07024265 for ; Mon, 28 Jan 2008 16:40:16 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m0SLeGn6024261; Mon, 28 Jan 2008 16:40:16 -0500 Date: Mon, 28 Jan 2008 16:40:16 -0500 Message-Id: <200801282140.m0SLeGn6024261@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <709921.15455.qm@web55709.mail.re3.yahoo.com> (haldebei@yahoo.com) Subject: Re: [Sip] SIP ack Method References: <709921.15455.qm@web55709.mail.re3.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: HOSSAM ALDEBEI when the SAU server (A) send an invite message to CommuniGate PBX (B) , the call occured with nothing heared from the PBX IVR system, after checking the Sip call flow on the trace we found that the last Ack after the 200 ok message sent in the "TO" field instead of "CONTACT" field as appeared which is not the same as that in RFC 3261, how can we solve this issue and force the CommuniGate to accept the ACK message . >From your description, it appears that the ACK (which is being generated by the SAU server) has an incorrect request-URI. So the SAU server needs to be corrected. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 29 16:44:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyFp-0000nL-E9; Tue, 29 Jan 2008 16:44:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJyFn-0000nG-GG for sip-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 16:44:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyFn-0000mk-47 for sip@ietf.org; Tue, 29 Jan 2008 16:44:27 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJyFm-000657-6K for sip@ietf.org; Tue, 29 Jan 2008 16:44:27 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 22:44:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Tue, 29 Jan 2008 22:44:21 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE069C088F@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-Index: Achh7sWNpD1HWRBFQwe5xXX69fUycgAznKvw From: To: X-OriginalArrivalTime: 29 Jan 2008 21:44:22.0335 (UTC) FILETIME=[1C045CF0:01C862C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: sip@ietf.org, drage@alcatel-lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think there is a misunderstanding on these use cases: - The intermediate entity in the customer side does perform only one = registration to the network. The AoRs associated to the served terminals = inside the client domain are registred automatically by the home = network, using implicit registration for example. In fact, it's not = conceivable to register individually all the users of a corporate = network for example. - The "intermediate entity" should be able to route incoming requests = inside its domain based on standard RFC3261 behaviour, that is, based on = the Request-URI. Best regards Youssef =20 =20 > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : lundi 28 janvier 2008 21:46 > =C0 : CHADLI Youssef RD-CORE-ISS > Cc : drage@alcatel-lucent.com; sip@ietf.org > Objet : Re: [Sip] Delivering request-URI and parameters to=20 > UAS via proxy >=20 > These cases can all be handled by having intermediate entity=20 > use a unique user part, together with its own domain name, to=20 > construct a contact address for each terminal UA that it is=20 > registering. Then when it receives an incoming request to one=20 > of these uris it can simply translate it, using the user part=20 > as a key to its own local mappings. >=20 > We don't need anything new to solve these cases. >=20 > Paul >=20 > youssef.chadli@orange-ftgroup.com wrote: > > =20 > > There are other cases similar to what is described in=20 > section 2.1 Unknown Aliases of J. Rosenberg draft that=20 > should be taken into account.=20 > >=20 > > Those cases are where the customer side is composed of=20 > several SIP terminals that access the network through an=20 > intermediate entity which registers their associated aliases=20 > with its contact address. Thus, such client side is seen from=20 > the network as a single client having several aliases=20 > (aggregated endpoints). Moreover, such client side may be a=20 > mini private network composed of several entities. In these=20 > configurations, the intermediate entity is in charge of=20 > routeing incoming calls inside the client domain and may need=20 > to behave as a SIP proxy for incoming SIP messages. =20 > >=20 > > As examples of such configuration: > > - Corporate networks: in that case the PBX register all the=20 > served individual user identities with its contact address=20 > and routes incoming calls toward the individual called users. > > - Home networks: the Home Gateway may need to register on=20 > behalf of all the served terminals. The Home Gateway is in=20 > charge of routeing incoming calls toward the individual called users.=20 > >=20 > > J. Rosenberg draft seems give a good solution to take into=20 > account these configurations. > > =20 > > Best regards, > >=20 > > Youssef > >=20 > >=20 > >> -----Message d'origine----- > >> De : DRAGE, Keith (Keith)=20 > [mailto:drage@alcatel-lucent.com] Envoy=E9 :=20 > >> lundi 14 janvier 2008 17:58 =C0 : sip@ietf.org Objet : [Sip]=20 > Delivering=20 > >> request-URI and parameters to UAS via proxy > >> > >> (As WG chair) > >> > >> In fulfilment of our charter items of > >> > >> Dec 2007 Delivering request-URI and parameters to UAS=20 > via proxy to > >> WGLC =20 > >> Feb 2008 Delivering request-URI and parameters to UAS=20 > via proxy to > >> IESG (PS) > >> > >> We now have a couple of proposals on the table for solving the=20 > >> problem. > >> > >> The original draft from Jonathan and which led to the=20 > creation of the=20 > >> charter items by the WG is unfortunately expired, but is at: > >> > >> http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt > >> > >> The alternative document from Christer, etc is at: > >> > >> http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- > >> uri-delive > >> ry-00.txt > >> > >> We obviously need to make a decision between the two approaches so=20 > >> please attempt to address the following specific points via the=20 > >> mailing > >> list: > >> > >> 1) Problem cases: These are summarised in section 4.4 of > >> draft-rosenberg-sip-ua-loose-route-01 and from my read of=20 > the other=20 > >> draft, I don't believe that this draft adds any others. > >> If you believe there are other cases that should be covered by the=20 > >> solution, then please identify them. If there is support=20 > on any new=20 > >> problem cases, I would encourage the authors of both drafts to add=20 > >> text concerning these problem cases. > >> > >> 2) Clarifications: If for any reason you don't understand either > >> draft, or believe that there are technical issues that are not=20 > >> represented in the current draft, please post your questions /=20 > >> comments to the list. I would encourage authors of both drafts to=20 > >> revise as frequently as appropriate to reflect the current=20 > state of=20 > >> discussion. > >> > >> 3) Support for either position. If you wish to indicate support for > >> either position please do so, but please accompany this is=20 > technical=20 > >> reasoning as to why you have this position, as that will=20 > help other=20 > >> members of the WG form a position. > >> > >> I would encourage as much list discussion as possible before=20 > >> Philadelphia. I suspect we will need to have a discussion at the=20 > >> face-to-face meeting in Philadephia, but list discussion=20 > is essential=20 > >> prior to that. If we can solve this positions on list,=20 > then well and=20 > >> good, and even better (that is how we are meant to make decisions). > >> > >> Regards > >> > >> > >> Keith > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jan 29 16:57:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJySp-0003Oq-38; Tue, 29 Jan 2008 16:57:55 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JJySm-0002ts-PK for sip-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 16:57:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJySm-0002mN-6r for sip@ietf.org; Tue, 29 Jan 2008 16:57:52 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJySj-0008NW-Ho for sip@ietf.org; Tue, 29 Jan 2008 16:57:52 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83A012156B; Tue, 29 Jan 2008 22:57:48 +0100 (CET) X-AuditID: c1b4fb3e-ad5edbb0000007e1-46-479fa15cfc5a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 650BA21549; Tue, 29 Jan 2008 22:57:48 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 22:57:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft Date: Tue, 29 Jan 2008 22:57:45 +0100 Message-ID: In-Reply-To: <479A4B4D.2090905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft thread-index: Achfk82PCFyOZLgaQ2i6drx261OyzwCLTTBA References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com> <478CEFB4.6070002@zonnet.nl> <0D5F89FAC29E2C41B98A6A762007F5D0593C0E@GBNTHT12009MSX.gb002.siemens.net> A <"C A9998CD 4A02 0D41 8654FCDEF4E7 07DF04173AE9"@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0593C68@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0593CFF@GBNTHT12009MSX.gb002.siemens.net> <479A4B4D .2090905 @cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "Elwell, John" X-OriginalArrivalTime: 29 Jan 2008 21:57:47.0942 (UTC) FILETIME=[FC323C60:01C862C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, >Sorry for jumping in late here. Trying to clarify some points=20 >here and there. >=20 >The UA-loose mechanism needs to know that the entity which=20 >would have previously been reached by the DNS/IP forwarding=20 >based on the R-URI, is now prepared for a request which=20 >reaches it with that target in the Route header field. >=20 >In the case of a UA registering through a chain of=20 >Path-inserting proxies, it means that only the *UA* has to=20 >support UA-loose route.=20 >Thats because of the assumption that the intermediate=20 >path-inserting proxies weren't being targeted based on the=20 >R-URI previously; they were (and still will) forward the=20 >request based on Route. > >The 'next hop' use case that Christer is referring to are=20 >cases where we would have done a R-URI translation without a=20 >registration. For example, lets say a proxy receives an=20 >INVITE with sip:12345@proxy.com, and its using some=20 >number-prefix based routing rules, which have been CONFIGURED=20 >into the proxy, to determine a next-hop gateway. The UA loose=20 >route rules would say that, since this is a routing operation=20 >and not a retargeting, the request looks like: >=20 >INVITE sip:12345@proxy.com >Route: sip:ip-of-gateway >=20 >whereas current rules would require: >=20 >INVITE sip:12345@ip-of-gateway >=20 >in this use case, the entity which was previously being=20 >reached by the R-URI *is* the next hop. >=20 >And so, the main limitation that I see of the UA loose route=20 >mechanism is, in cases where the next-hop is being reached=20 >via a configured routing rule, or by some other=20 >non-registration means, and said operation is a re-route and=20 >not retarget, the UA_loose-route requires that this=20 >configured routing rule include information about whether the=20 >next hop uses UA loose routing, and if so, what URI to use in=20 >the Route header. >=20 >This is a limitation, I agree. Whether its significant or not=20 >is debatable. >=20 >I will note that, it is possible to separate these concerns.=20 >We could define UA loose route to strictly be used for the=20 >registration cases, since that is the specific problem at hand. >=20 >I agree CHrister's mechanism does not have this configuration=20 >limitation, and that this aspect of it is better. My main=20 >beef, as others have commented, is that it leaves us with=20 >nearly half-dozen header fields which are all awfully similar=20 >(To, P-C-ID, Route, History-Info, and now Target). I was=20 >hoping to reduce the set and include only the minimum. In=20 >that way, I think UA loose route is architecturally better=20 >since it gives some clarity to this. I don't think a solution with the configuration limitation is architecturally better. =20 However, there is also a possibility to merge both solution proposals: UA-loose-route would be used from the home proxy towards the UE (giving Request-URI the same semantics as P-Called-Party-ID has today), and Target to convey the current target. Yes, we would have another header. But, the new header would have clear semantics, and we would get rid of the configuration limitation. (Another possibility that does not require a new header is to fix the semantics of the To header and allow it to be modified, but that may have unwanted backward compatibility issues.) The merged solution would probably also solve the issues raised by Youssef - eventhough the "intermediate entity" (being a B2BUA) he is talking about could as well map the Target header into a R-URI. However we think it would be good to additionally cover the use case that is behind this in the UALR work to justify such a combined solution. Regards, Christer >=20 > Elwell, John wrote: > > Christer, > >=20 > > I don't think the entity using the mechanism needs to know=20 > about next=20 > > hop support for the loose route mechanism - only whether the UAS=20 > > supports it. If the UA registers, then the loose route=20 > draft provides=20 > > an automatic mechanism. If the UA does not register, support would=20 > > need to be indicated by provisioning. I am not sure this ranks as a=20 > > significant limitation, since a certain amount of=20 > provisioning needs=20 > > to be done anyway for UAs such as gateways that do not register. > >=20 > > John > >=20 > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: 16 January 2008 11:51 > >> To: Elwell, John; sip@ietf.org > >> Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > >> Subject: RE: [Sip] RE: Delivering request-URI and=20 > parameters to UAS=20 > >> via proxy -new version of the=20 > draft-holmberg-sip-target-uri-delivery=20 > >> draft > >> > >> > >> Hi, > >> > >>> I hear what you are saying, but I don't really see that the > >> points you > >> raised in section 4 are real limitations of the loose=20 > route mechanism. > >> > >> I think it is a limitation that an entity using the=20 > mechanism has to=20 > >> know whether the the next hop supports it or not, and that the=20 > >> mechanism can only be used if the subsequent hops support it. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >>>> -----Original Message----- > >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>> Sent: 16 January 2008 11:06 > >>>> To: Elwell, John; sip@ietf.org > >>>> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > >>>> Subject: [Sip] RE: Delivering request-URI and parameters > >> to UAS via > >>>> proxy - new version of the draft-holmberg-sip-target-uri-delivery > >>>> draft > >>>> > >>>> > >>>> Hi John, > >>>> > >>>>> Thanks for this revision, which makes things somewhat > >>> clearer. I do > >>>>> have a couple of comments: > >>>>> > >>>>> 1. I am not sure I agree with the assertions in section 4 > >>> concerning > >>>>> issues with the mechanisms in loose-route. Taking=20 > example 1, the=20 > >>>>> Route header field should contain enough entries to get > >> you to the > >>>>> registered contact, not just to an intermediate proxy.=20 > >>> Therefore this > >>>>> situation should not arise with a correctly implemented > >>> home proxy.=20 > >>>>> It is not clear to me how example 2 could arise either, > >>> for similar > >>>>> reasons. The MGC case can be resolved by taking into=20 > account the=20 > >>>>> option tag in the REGISTER request, or if it is permanently=20 > >>>>> registered, through provisioning. > >>>> The examples are not meant to show bugs in the loose-route > >>> mechanism. > >>>> They are meant to help people understand the limitations=20 > with the=20 > >>>> loose-route mechanism. > >>>> =20 > >>>>> 2. Comparing the mechanism proposed with the loose-route > >>> mechanism, > >>>>> my understanding is: > >>>>> a)When retargeting occurs, the loose-route mechanism > >>> places the new > >>>>> target in the Request URI. Your proposal places the new > >> target in > >>>>> both the Request-URI and the Target header field. > >>>>> b) When rerouting, the loose-route mechanism places the > >> new route > >>>>> (i.e., the registered contact) in the Route header field. Your=20 > >>>>> proposal places the new route in the Request-URI (the > >>> latter as per > >>>>> RFC 3261). > >>>>> So the two mechanisms solve exactly the same problems using a=20 > >>>>> slightly different mechanism. Correct? > >>>> Yes. The two solutions intend to solve the same problem. > >>>> =20 > >>>>> 3. How P-Called-Party-ID fits into this is not really > >>> relevant from > >>>>> an IETF perspective - it seems there are some 3GPP-specific=20 > >>>>> situations where the contents of P-Called-Party-ID will > >>> not equal the > >>>>> contents of Target. Correct? > >>>> Correct. > >>>> > >>>>> 4. If my suggestion in point 1 above that the loose-route > >>> mechanism > >>>>> does not suffer from the problems suggested, then each > >>> mechanism will > >>>>> work and each addresses the same problem. > >>>>> So it is just down to a beauty contest between the two. Correct? > >>>> See question 1. > >>>> > >>>> We believe that our solution does not have the same > >>> limitations as the > >>>> loose-route solution. But, again, both solutions intend to > >>> solve the > >>>> same problem. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Christer Holmberg > >> [mailto:christer.holmberg@ericsson.com] > >>>>>> Sent: 16 January 2008 08:41 > >>>>>> To: sip@ietf.org > >>>>>> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > >>> Jeroen van > >>>>>> Bemmel; Francois Audet > >>>>>> Subject: Delivering request-URI and parameters to UAS via > >>>>> proxy - new > >>>>>> version of the draft-holmberg-sip-target-uri-delivery draft > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> We've uploaded a new version (-01) of the Target draft. > >>>>>> > >>>>>> We've tried to make things more clear. I've also > >>> removed all text > >>>>>> about P-Called-Party-ID, except from one chapter where > >>> we try to > >>>>>> explain the semantical difference between Target and P-CPI. > >>>>>> > >>>>>> You can also find the draft from: > >>>>>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > >>>>>> et-uri-del > >>>>>> ivery-01.txt > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@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=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 30 10:12:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKEbQ-00059q-8R; Wed, 30 Jan 2008 10:11:52 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKEbO-00050O-OA for sip-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 10:11:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKEbO-0004ur-AH for sip@ietf.org; Wed, 30 Jan 2008 10:11:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKEbN-0005u8-BX for sip@ietf.org; Wed, 30 Jan 2008 10:11:50 -0500 X-IronPort-AV: E=Sophos;i="4.25,277,1199682000"; d="scan'208";a="84999304" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Jan 2008 10:11:47 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0UFBjMr007622; Wed, 30 Jan 2008 10:11:45 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0UFBaJB002975; Wed, 30 Jan 2008 15:11:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 10:11:34 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 10:11:34 -0500 Message-ID: <47A093AC.9090507@cisco.com> Date: Wed, 30 Jan 2008 10:11:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: youssef.chadli@orange-ftgroup.com Subject: Re: [Sip] Delivering request-URI and parameters to UAS via proxy References: <2AF8FF7D89242541B12E7A47F6ECB4BE069C088F@ftrdmel3> In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE069C088F@ftrdmel3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jan 2008 15:11:34.0130 (UTC) FILETIME=[66AF6D20:01C86352] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7494; t=1201705905; x=1202569905; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Delivering=20request-URI=20and= 20parameters=20to=20UAS=20via=20proxy |Sender:=20 |To:=20youssef.chadli@orange-ftgroup.com; bh=XChJIVgrd+xO1mlrtOILBlZZweUK/XBsPuMIXNFpbT8=; b=z0sng2o4TF7dhMPEIuhggzkS4+vsRAblNhWaJS7taHOMhUXSDFOhvLb/xl /WPw0tKWrVpgbW6atYyFlrdaP6rIXZAEKG3TmrOULYGoSrfPyEnySqqyG9pS c9jxhtatuR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: sip@ietf.org, drage@alcatel-lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org youssef.chadli@orange-ftgroup.com wrote: > I think there is a misunderstanding on these use cases: Quite possible. > - The intermediate entity in the customer side does perform only one registration to the network. > The AoRs associated to the served terminals inside the client domain are registred automatically > by the home network, using implicit registration for example. In fact, it's not conceivable to > register individually all the users of a corporate network for example. You seem to be describing one of the models covered by the SIPForum in their SIPConnect specification. Is that what you mean? From the point of view of the registrar this seems similar to IMS implicit registration, except that the scale is much larger - there may be *very many* implicit registrations generated by this one explicit registration. > - The "intermediate entity" should be able to route incoming requests inside its domain based on > standard RFC3261 behaviour, that is, based on the Request-URI. I find the case much less compelling than the IMS case. IMO this is an abuse of REGISTER to a purpose for which it is not well suited. Treating it as registration means that there is an *expectation* that the R-URI will be translated. That isn't really appropriate in this case. The registration doesn't specify the mapping anyway - it is configuration in the network of all the addresses that belong to the "pbx" that does that. This is more appropriately viewed as just a routing operation, and so pushing the address of the enterprise server as a Route header is by far the best choice. Its only because this has been done using REGISTER that brings up how to preserve the old address when it is translated. Thanks, Paul > Best regards > > Youssef > > > > > >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Envoyé : lundi 28 janvier 2008 21:46 >> À : CHADLI Youssef RD-CORE-ISS >> Cc : drage@alcatel-lucent.com; sip@ietf.org >> Objet : Re: [Sip] Delivering request-URI and parameters to >> UAS via proxy >> >> These cases can all be handled by having intermediate entity >> use a unique user part, together with its own domain name, to >> construct a contact address for each terminal UA that it is >> registering. Then when it receives an incoming request to one >> of these uris it can simply translate it, using the user part >> as a key to its own local mappings. >> >> We don't need anything new to solve these cases. >> >> Paul >> >> youssef.chadli@orange-ftgroup.com wrote: >>> >>> There are other cases similar to what is described in >> section 2.1 Unknown Aliases of J. Rosenberg draft that >> should be taken into account. >>> Those cases are where the customer side is composed of >> several SIP terminals that access the network through an >> intermediate entity which registers their associated aliases >> with its contact address. Thus, such client side is seen from >> the network as a single client having several aliases >> (aggregated endpoints). Moreover, such client side may be a >> mini private network composed of several entities. In these >> configurations, the intermediate entity is in charge of >> routeing incoming calls inside the client domain and may need >> to behave as a SIP proxy for incoming SIP messages. >>> As examples of such configuration: >>> - Corporate networks: in that case the PBX register all the >> served individual user identities with its contact address >> and routes incoming calls toward the individual called users. >>> - Home networks: the Home Gateway may need to register on >> behalf of all the served terminals. The Home Gateway is in >> charge of routeing incoming calls toward the individual called users. >>> J. Rosenberg draft seems give a good solution to take into >> account these configurations. >>> >>> Best regards, >>> >>> Youssef >>> >>> >>>> -----Message d'origine----- >>>> De : DRAGE, Keith (Keith) >> [mailto:drage@alcatel-lucent.com] Envoyé : >>>> lundi 14 janvier 2008 17:58 À : sip@ietf.org Objet : [Sip] >> Delivering >>>> request-URI and parameters to UAS via proxy >>>> >>>> (As WG chair) >>>> >>>> In fulfilment of our charter items of >>>> >>>> Dec 2007 Delivering request-URI and parameters to UAS >> via proxy to >>>> WGLC >>>> Feb 2008 Delivering request-URI and parameters to UAS >> via proxy to >>>> IESG (PS) >>>> >>>> We now have a couple of proposals on the table for solving the >>>> problem. >>>> >>>> The original draft from Jonathan and which led to the >> creation of the >>>> charter items by the WG is unfortunately expired, but is at: >>>> >>>> http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt >>>> >>>> The alternative document from Christer, etc is at: >>>> >>>> http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- >>>> uri-delive >>>> ry-00.txt >>>> >>>> We obviously need to make a decision between the two approaches so >>>> please attempt to address the following specific points via the >>>> mailing >>>> list: >>>> >>>> 1) Problem cases: These are summarised in section 4.4 of >>>> draft-rosenberg-sip-ua-loose-route-01 and from my read of >> the other >>>> draft, I don't believe that this draft adds any others. >>>> If you believe there are other cases that should be covered by the >>>> solution, then please identify them. If there is support >> on any new >>>> problem cases, I would encourage the authors of both drafts to add >>>> text concerning these problem cases. >>>> >>>> 2) Clarifications: If for any reason you don't understand either >>>> draft, or believe that there are technical issues that are not >>>> represented in the current draft, please post your questions / >>>> comments to the list. I would encourage authors of both drafts to >>>> revise as frequently as appropriate to reflect the current >> state of >>>> discussion. >>>> >>>> 3) Support for either position. If you wish to indicate support for >>>> either position please do so, but please accompany this is >> technical >>>> reasoning as to why you have this position, as that will >> help other >>>> members of the WG form a position. >>>> >>>> I would encourage as much list discussion as possible before >>>> Philadelphia. I suspect we will need to have a discussion at the >>>> face-to-face meeting in Philadephia, but list discussion >> is essential >>>> prior to that. If we can solve this positions on list, >> then well and >>>> good, and even better (that is how we are meant to make decisions). >>>> >>>> Regards >>>> >>>> >>>> Keith >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@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@cs.columbia.edu for questions on current sip Use >>> sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 30 10:38:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKF1W-0001bz-5Z; Wed, 30 Jan 2008 10:38:50 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKF1U-0001af-2K for sip-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 10:38:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKF1T-0001aV-OE; Wed, 30 Jan 2008 10:38:47 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKF1T-0003oa-D9; Wed, 30 Jan 2008 10:38:47 -0500 Received: from [127.0.0.1] (takahe.estacado.net [72.1.129.96]) (authenticated bits=0) by estacado.net (8.14.1/8.14.1) with ESMTP id m0UFcfSZ044650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jan 2008 09:38:44 -0600 (CST) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List , sipping LIST , simple mailing list From: Robert Sparks Date: Wed, 30 Jan 2008 10:38:39 -0500 X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Sip] Registration for SIPit 22 is open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIPit 22 will be hosted by the University of New Hampshire Interoperability Laboratory April 14 through 18, 2008. Registration is $350 (USD) per person. Registration will close April 4. Space is limited, so register early to ensure a seat. Additional registration details are available at http://www.sipit.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 30 14:19:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKISd-0001Lr-A5; Wed, 30 Jan 2008 14:19:03 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKISb-0001Lm-G6 for sip-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 14:19:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKISb-0001Le-4e for sip@ietf.org; Wed, 30 Jan 2008 14:19:01 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKISa-0005W7-Al for sip@ietf.org; Wed, 30 Jan 2008 14:19:00 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m0UJIimM003624; Wed, 30 Jan 2008 13:18:52 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 13:18:36 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 20:18:34 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 Date: Wed, 30 Jan 2008 20:18:33 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BB7CE2@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180019F7594@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 Thread-index: Acg5CAVYvVaurdFmT0G+mU6ExOtR0AqbKTcw References: <5D1A7985295922448D5550C94DE29180019F7594@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "DRAGE, Keith \(Keith\)" , X-OriginalArrivalTime: 30 Jan 2008 19:18:34.0228 (UTC) FILETIME=[E826EB40:01C86374] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: slawrence@bluesocket.com, alan.ietf@polyphase.ca X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) There were no comments in response to this WGLC, so I propose to submit a publish request for it shortly. If it is still on your pending list to look at, then immediately would be a good time to get round to it. Regards Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Friday, December 07, 2007 7:33 PM > To: sip@ietf.org > Cc: alan.ietf@polyphase.ca; slawrence@bluesocket.com > Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 >=20 > (As WG chair) >=20 > This document has a somewhat complicated history, in that we=20 > completed it once in the WG and sent it to the IESG, but it=20 > came back from them because of concerns over security issues. >=20 > The editor's have now followed the instructions from the=20 > previous meeting, i.e. to: >=20 > Integrated Max-Breadth based on working group discussion of the > secdir review >=20 > Added a paragraph pointing out that removing or modifying other > node's branch parameters defeats their ability to loop detect >=20 > Moved the total number of messages from O(2^70) to O(2^71) based > on an observation by Jan Kolomaznik. To see this, note that the > total number of requests is the sum from i=3D0 to Max-Forwards = of > 2^i which is 2^(Max-Forwards+1) - 1. The point of the text > doesn't change - (the point being that the number is _big_). >=20 > Made the new 4xx concrete (choosing 440) >=20 > Added a sentence reinforcing that if you forward to only one > branch, you still potentially have a constant multiplier of > messages in the network as Max-Forwards runs out (based on > feedback from Thomas Cross.) >=20 > These changes are significant enough to justify a revised=20 > WGLC, and I would therefore like the working group to review=20 > the document and provide comments to the SIP list and authors by=20 >=20 > Friday 21st December 2007.=20 >=20 > It would be appropriate to concentrate on the text with the=20 > changes identified about. >=20 > The document may be found at: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-f > ix-06.txt >=20 > And the wdiff document may be found at: >=20 > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dhttp://to > ols.ietf.o > rg/id/draft-ietf-sip-fork-loop-fix-06.txt >=20 > [Note that unfortunately this identifies a significant=20 > portion of text as new text, when it fact it merely moved.] >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 30 19:22:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNBy-00027m-7T; Wed, 30 Jan 2008 19:22:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKNBx-00027h-6l for sip-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 19:22:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNBw-00027Y-T7 for sip@ietf.org; Wed, 30 Jan 2008 19:22:08 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKNBu-0006UJ-KP for sip@ietf.org; Wed, 30 Jan 2008 19:22:08 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 01:22:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Thu, 31 Jan 2008 01:21:59 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE069C10DE@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-Index: AchjUm/Osur5BaNRQA+Cq33/82CMNAASb4MQ From: To: X-OriginalArrivalTime: 31 Jan 2008 00:22:03.0152 (UTC) FILETIME=[4D843900:01C8639F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: sip@ietf.org, drage@alcatel-lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Inline Youssef > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : mercredi 30 janvier 2008 16:12 > =C0 : CHADLI Youssef RD-CORE-ISS > Cc : drage@alcatel-lucent.com; sip@ietf.org > Objet : Re: [Sip] Delivering request-URI and parameters to=20 > UAS via proxy >=20 >=20 >=20 > youssef.chadli@orange-ftgroup.com wrote: > > I think there is a misunderstanding on these use cases: >=20 > Quite possible. >=20 > > - The intermediate entity in the customer side does=20 > perform only one registration to the network. > > The AoRs associated to the served terminals inside the=20 > client domain are registred automatically > > by the home network, using implicit registration for=20 > example. In fact, it's not conceivable to > > register individually all the users of a corporate=20 > network for example. >=20 > You seem to be describing one of the models covered by the=20 > SIPForum in their SIPConnect specification. Is that what you mean? The model described in Sipconnect is an example of such configuration. = As I mentionned before there other cases such as home networks and other = configurations of connecting corporate networks. =20 > From the point of view of the registrar this seems similar=20 > to IMS implicit registration, except that the scale is much=20 > larger - there may be *very many* implicit registrations=20 > generated by this one explicit registration. Agreed >=20 > > - The "intermediate entity" should be able to route=20 > incoming requests inside its domain based on > > standard RFC3261 behaviour, that is, based on the Request-URI. >=20 > I find the case much less compelling than the IMS case. >=20 > IMO this is an abuse of REGISTER to a purpose for which it is=20 > not well suited. >=20 > Treating it as registration means that there is an=20 > *expectation* that the R-URI will be translated. That isn't=20 > really appropriate in this case. The registration doesn't=20 > specify the mapping anyway - it is configuration in the=20 > network of all the addresses that belong to the "pbx" that=20 > does that. This is more appropriately viewed as just a=20 > routing operation, and so pushing the address of the=20 > enterprise server as a Route header is by far the best=20 > choice. Its only because this has been done using REGISTER=20 > that brings up how to preserve the old address when it is translated. Agreed >=20 > Thanks, > Paul >=20 > > Best regards > >=20 > > Youssef > >=20 > >=20 > > =20 > > =20 > >=20 > >> -----Message d'origine----- > >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] Envoy=E9 : lundi 28=20 > >> janvier 2008 21:46 =C0 : CHADLI Youssef RD-CORE-ISS Cc :=20 > >> drage@alcatel-lucent.com; sip@ietf.org Objet : Re: [Sip]=20 > Delivering=20 > >> request-URI and parameters to UAS via proxy > >> > >> These cases can all be handled by having intermediate entity use a=20 > >> unique user part, together with its own domain name, to=20 > construct a=20 > >> contact address for each terminal UA that it is registering. Then=20 > >> when it receives an incoming request to one of these uris it can=20 > >> simply translate it, using the user part as a key to its own local=20 > >> mappings. > >> > >> We don't need anything new to solve these cases. > >> > >> Paul > >> > >> youssef.chadli@orange-ftgroup.com wrote: > >>> =20 > >>> There are other cases similar to what is described in > >> section 2.1 Unknown Aliases of J. Rosenberg draft that should be=20 > >> taken into account. > >>> Those cases are where the customer side is composed of > >> several SIP terminals that access the network through an=20 > intermediate=20 > >> entity which registers their associated aliases with its contact=20 > >> address. Thus, such client side is seen from the network=20 > as a single=20 > >> client having several aliases (aggregated endpoints).=20 > Moreover, such=20 > >> client side may be a mini private network composed of several=20 > >> entities. In these configurations, the intermediate entity is in=20 > >> charge of routeing incoming calls inside the client domain and may=20 > >> need to behave as a SIP proxy for incoming SIP messages. > >>> As examples of such configuration: > >>> - Corporate networks: in that case the PBX register all the > >> served individual user identities with its contact address=20 > and routes=20 > >> incoming calls toward the individual called users. > >>> - Home networks: the Home Gateway may need to register on > >> behalf of all the served terminals. The Home Gateway is=20 > in charge of=20 > >> routeing incoming calls toward the individual called users. > >>> J. Rosenberg draft seems give a good solution to take into > >> account these configurations. > >>> =20 > >>> Best regards, > >>> > >>> Youssef > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : DRAGE, Keith (Keith) > >> [mailto:drage@alcatel-lucent.com] Envoy=E9 :=20 > >>>> lundi 14 janvier 2008 17:58 =C0 : sip@ietf.org Objet : [Sip] > >> Delivering > >>>> request-URI and parameters to UAS via proxy > >>>> > >>>> (As WG chair) > >>>> > >>>> In fulfilment of our charter items of > >>>> > >>>> Dec 2007 Delivering request-URI and parameters to UAS=20 > >> via proxy to > >>>> WGLC =20 > >>>> Feb 2008 Delivering request-URI and parameters to UAS=20 > >> via proxy to > >>>> IESG (PS) > >>>> > >>>> We now have a couple of proposals on the table for solving the=20 > >>>> problem. > >>>> > >>>> The original draft from Jonathan and which led to the > >> creation of the > >>>> charter items by the WG is unfortunately expired, but is at: > >>>> > >>>>=20 > http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt > >>>> > >>>> The alternative document from Christer, etc is at: > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-holmberg-sip-target- > >>>> uri-delive > >>>> ry-00.txt > >>>> > >>>> We obviously need to make a decision between the two=20 > approaches so=20 > >>>> please attempt to address the following specific points via the=20 > >>>> mailing > >>>> list: > >>>> > >>>> 1) Problem cases: These are summarised in section 4.4 of > >>>> draft-rosenberg-sip-ua-loose-route-01 and from my read of > >> the other > >>>> draft, I don't believe that this draft adds any others. > >>>> If you believe there are other cases that should be=20 > covered by the=20 > >>>> solution, then please identify them. If there is support > >> on any new > >>>> problem cases, I would encourage the authors of both=20 > drafts to add=20 > >>>> text concerning these problem cases. > >>>> > >>>> 2) Clarifications: If for any reason you don't=20 > understand either > >>>> draft, or believe that there are technical issues that are not=20 > >>>> represented in the current draft, please post your questions /=20 > >>>> comments to the list. I would encourage authors of both=20 > drafts to=20 > >>>> revise as frequently as appropriate to reflect the current > >> state of > >>>> discussion. > >>>> > >>>> 3) Support for either position. If you wish to=20 > indicate support for > >>>> either position please do so, but please accompany this is > >> technical > >>>> reasoning as to why you have this position, as that will > >> help other > >>>> members of the WG form a position. > >>>> > >>>> I would encourage as much list discussion as possible before=20 > >>>> Philadelphia. I suspect we will need to have a discussion at the=20 > >>>> face-to-face meeting in Philadephia, but list discussion > >> is essential > >>>> prior to that. If we can solve this positions on list, > >> then well and > >>>> good, and even better (that is how we are meant to make=20 > decisions). > >>>> > >>>> Regards > >>>> > >>>> > >>>> Keith > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@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=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 30 20:58:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKOhG-0002QX-Mj; Wed, 30 Jan 2008 20:58:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKOhF-0002QQ-85 for sip-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 20:58:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKOhE-0002QI-UW for sip@ietf.org; Wed, 30 Jan 2008 20:58:32 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKOhC-0000Pe-1U for sip@ietf.org; Wed, 30 Jan 2008 20:58:32 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 02:58:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft Date: Thu, 31 Jan 2008 02:58:23 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE069C10E3@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Delivering request-URI and parameters to UAS via proxy-new version of the draft-holmberg-sip-target-uri-delivery draft Thread-Index: Achfk82PCFyOZLgaQ2i6drx261OyzwCLTTBAAHja8xA= From: To: , , X-OriginalArrivalTime: 31 Jan 2008 01:58:27.0246 (UTC) FILETIME=[C51AECE0:01C863AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: sip@ietf.org, pkyzivat@cisco.com, drage@alcatel-lucent.com, audet@nortel.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 The merged solution proposed by Christer would have the following = advantages:=20 - The "UA loose route" mechanism would solve the "registration cases", = particularly the problem of routing incoming sessions to the right = terminal where the client side is composed of several endpoints = accessing the network through an intermediate entity which registers = their associated aliases with its contact address (see the thread = discussing these use cases). - The Target header would solve the backward compatibility limitation = for the other cases. Regards,=20 Youssef =20 > -----Message d'origine----- > De : Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Envoy=E9 : mardi 29 janvier 2008 22:58 > =C0 : Jonathan Rosenberg; Elwell, John > Cc : sip@ietf.org; Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > Objet : RE: [Sip] RE: Delivering request-URI and parameters=20 > to UAS via proxy-new version of the=20 > draft-holmberg-sip-target-uri-delivery draft >=20 >=20 > Hi Jonathan, >=20 > >Sorry for jumping in late here. Trying to clarify some=20 > points here and=20 > >there. > >=20 > >The UA-loose mechanism needs to know that the entity which=20 > would have=20 > >previously been reached by the DNS/IP forwarding based on=20 > the R-URI, is=20 > >now prepared for a request which reaches it with that target in the=20 > >Route header field. > >=20 > >In the case of a UA registering through a chain of Path-inserting=20 > >proxies, it means that only the *UA* has to support UA-loose route. > >Thats because of the assumption that the intermediate path-inserting=20 > >proxies weren't being targeted based on the R-URI=20 > previously; they were=20 > >(and still will) forward the request based on Route. > > > >The 'next hop' use case that Christer is referring to are=20 > cases where=20 > >we would have done a R-URI translation without a registration. For=20 > >example, lets say a proxy receives an INVITE with=20 > sip:12345@proxy.com,=20 > >and its using some number-prefix based routing rules, which=20 > have been=20 > >CONFIGURED into the proxy, to determine a next-hop gateway. The UA=20 > >loose route rules would say that, since this is a routing=20 > operation and=20 > >not a retargeting, the request looks like: > >=20 > >INVITE sip:12345@proxy.com > >Route: sip:ip-of-gateway > >=20 > >whereas current rules would require: > >=20 > >INVITE sip:12345@ip-of-gateway > >=20 > >in this use case, the entity which was previously being=20 > reached by the=20 > >R-URI *is* the next hop. > >=20 > >And so, the main limitation that I see of the UA loose route=20 > mechanism=20 > >is, in cases where the next-hop is being reached via a configured=20 > >routing rule, or by some other non-registration means, and said=20 > >operation is a re-route and not retarget, the UA_loose-route=20 > requires=20 > >that this configured routing rule include information about=20 > whether the=20 > >next hop uses UA loose routing, and if so, what URI to use=20 > in the Route=20 > >header. > >=20 > >This is a limitation, I agree. Whether its significant or not is=20 > >debatable. > >=20 > >I will note that, it is possible to separate these concerns.=20 > >We could define UA loose route to strictly be used for the=20 > registration=20 > >cases, since that is the specific problem at hand. > >=20 > >I agree CHrister's mechanism does not have this configuration=20 > >limitation, and that this aspect of it is better. My main beef, as=20 > >others have commented, is that it leaves us with nearly half-dozen=20 > >header fields which are all awfully similar (To, P-C-ID, Route,=20 > >History-Info, and now Target). I was hoping to reduce the set and=20 > >include only the minimum. In that way, I think UA loose route is=20 > >architecturally better since it gives some clarity to this. >=20 > I don't think a solution with the configuration limitation is=20 > architecturally better. =20 >=20 > However, there is also a possibility to merge both solution proposals: > UA-loose-route would be used from the home proxy towards the=20 > UE (giving Request-URI the same semantics as=20 > P-Called-Party-ID has today), and Target to convey the=20 > current target. Yes, we would have another header. > But, the new header would have clear semantics, and we would=20 > get rid of the configuration limitation. (Another possibility=20 > that does not require a new header is to fix the semantics of=20 > the To header and allow it to be modified, but that may have=20 > unwanted backward compatibility issues.) >=20 > The merged solution would probably also solve the issues=20 > raised by Youssef - eventhough the "intermediate entity"=20 > (being a B2BUA) he is talking about could as well map the=20 > Target header into a R-URI. However we think it would be good=20 > to additionally cover the use case that is behind this in the=20 > UALR work to justify such a combined solution. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >=20 > > Elwell, John wrote: > > > Christer, > > >=20 > > > I don't think the entity using the mechanism needs to know > > about next > > > hop support for the loose route mechanism - only whether the UAS=20 > > > supports it. If the UA registers, then the loose route > > draft provides > > > an automatic mechanism. If the UA does not register,=20 > support would=20 > > > need to be indicated by provisioning. I am not sure this=20 > ranks as a=20 > > > significant limitation, since a certain amount of > > provisioning needs > > > to be done anyway for UAs such as gateways that do not register. > > >=20 > > > John > > >=20 > > >> -----Original Message----- > > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > >> Sent: 16 January 2008 11:51 > > >> To: Elwell, John; sip@ietf.org > > >> Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet > > >> Subject: RE: [Sip] RE: Delivering request-URI and > > parameters to UAS > > >> via proxy -new version of the > > draft-holmberg-sip-target-uri-delivery > > >> draft > > >> > > >> > > >> Hi, > > >> > > >>> I hear what you are saying, but I don't really see that the > > >> points you > > >> raised in section 4 are real limitations of the loose > > route mechanism. > > >> > > >> I think it is a limitation that an entity using the > > mechanism has to > > >> know whether the the next hop supports it or not, and that the=20 > > >> mechanism can only be used if the subsequent hops support it. > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> > > >> > > >>>> -----Original Message----- > > >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > >>>> Sent: 16 January 2008 11:06 > > >>>> To: Elwell, John; sip@ietf.org > > >>>> Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet > > >>>> Subject: [Sip] RE: Delivering request-URI and parameters > > >> to UAS via > > >>>> proxy - new version of the=20 > draft-holmberg-sip-target-uri-delivery > > >>>> draft > > >>>> > > >>>> > > >>>> Hi John, > > >>>> > > >>>>> Thanks for this revision, which makes things somewhat > > >>> clearer. I do > > >>>>> have a couple of comments: > > >>>>> > > >>>>> 1. I am not sure I agree with the assertions in section 4 > > >>> concerning > > >>>>> issues with the mechanisms in loose-route. Taking > > example 1, the > > >>>>> Route header field should contain enough entries to get > > >> you to the > > >>>>> registered contact, not just to an intermediate proxy.=20 > > >>> Therefore this > > >>>>> situation should not arise with a correctly implemented > > >>> home proxy.=20 > > >>>>> It is not clear to me how example 2 could arise either, > > >>> for similar > > >>>>> reasons. The MGC case can be resolved by taking into > > account the > > >>>>> option tag in the REGISTER request, or if it is permanently=20 > > >>>>> registered, through provisioning. > > >>>> The examples are not meant to show bugs in the loose-route > > >>> mechanism. > > >>>> They are meant to help people understand the limitations > > with the > > >>>> loose-route mechanism. > > >>>> =20 > > >>>>> 2. Comparing the mechanism proposed with the loose-route > > >>> mechanism, > > >>>>> my understanding is: > > >>>>> a)When retargeting occurs, the loose-route mechanism > > >>> places the new > > >>>>> target in the Request URI. Your proposal places the new > > >> target in > > >>>>> both the Request-URI and the Target header field. > > >>>>> b) When rerouting, the loose-route mechanism places the > > >> new route > > >>>>> (i.e., the registered contact) in the Route header=20 > field. Your=20 > > >>>>> proposal places the new route in the Request-URI (the > > >>> latter as per > > >>>>> RFC 3261). > > >>>>> So the two mechanisms solve exactly the same problems using a=20 > > >>>>> slightly different mechanism. Correct? > > >>>> Yes. The two solutions intend to solve the same problem. > > >>>> =20 > > >>>>> 3. How P-Called-Party-ID fits into this is not really > > >>> relevant from > > >>>>> an IETF perspective - it seems there are some 3GPP-specific=20 > > >>>>> situations where the contents of P-Called-Party-ID will > > >>> not equal the > > >>>>> contents of Target. Correct? > > >>>> Correct. > > >>>> > > >>>>> 4. If my suggestion in point 1 above that the loose-route > > >>> mechanism > > >>>>> does not suffer from the problems suggested, then each > > >>> mechanism will > > >>>>> work and each addresses the same problem. > > >>>>> So it is just down to a beauty contest between the=20 > two. Correct? > > >>>> See question 1. > > >>>> > > >>>> We believe that our solution does not have the same > > >>> limitations as the > > >>>> loose-route solution. But, again, both solutions intend to > > >>> solve the > > >>>> same problem. > > >>>> > > >>>> Regards, > > >>>> > > >>>> Christer > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Christer Holmberg > > >> [mailto:christer.holmberg@ericsson.com] > > >>>>>> Sent: 16 January 2008 08:41 > > >>>>>> To: sip@ietf.org > > >>>>>> Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John; > > >>> Jeroen van > > >>>>>> Bemmel; Francois Audet > > >>>>>> Subject: Delivering request-URI and parameters to UAS via > > >>>>> proxy - new > > >>>>>> version of the draft-holmberg-sip-target-uri-delivery draft > > >>>>>> > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> We've uploaded a new version (-01) of the Target draft. > > >>>>>> > > >>>>>> We've tried to make things more clear. I've also > > >>> removed all text > > >>>>>> about P-Called-Party-ID, except from one chapter where > > >>> we try to > > >>>>>> explain the semantical difference between Target and P-CPI. > > >>>>>> > > >>>>>> You can also find the draft from: > > >>>>>>=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ > > >>>>>> et-uri-del > > >>>>>> ivery-01.txt > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>>> Christer > > >>>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>>> This list is for NEW development of the core SIP Protocol Use=20 > > >>>> sip-implementors@cs.columbia.edu for questions on > > current sip Use > > >>>> sipping@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=20 > > >>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >>> sipping@ietf.org for new developments on the application of sip > > >>> > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > Cisco Fellow Edison, NJ 08837 > > Cisco, Voice Technology Group > > jdrosen@cisco.com > > http://www.jdrosen.net PHONE: (408) 902-3084 > > http://www.cisco.com > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jan 30 23:32:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKR61-00048h-VQ; Wed, 30 Jan 2008 23:32:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKR61-00048Y-1P for sip-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 23:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKR60-00048Q-LV for sip@ietf.org; Wed, 30 Jan 2008 23:32:16 -0500 Received: from nestgroup.net ([203.200.157.75] helo=mx-01.nestgroup.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKR5w-0002XX-4B for sip@ietf.org; Wed, 30 Jan 2008 23:32:16 -0500 Received: from MAIL-TVM.tvm.nestgroup.net ([192.168.192.74]) by mx-01.nestgroup.net (8.13.1/8.13.1) with ESMTP id m0V4bO4s032671 for ; Thu, 31 Jan 2008 10:09:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jan 2008 10:00:29 +0530 Message-ID: <9A1299C7A40D7447A108107E951450CA05ACF56E@MAIL-TVM.tvm.nestgroup.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extension mobility in SIP Thread-Index: AchjwgIqke7WRnoZRqOX7UhW6r/qoA== From: "Anisha Kumar" To: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on MX-01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] Extension mobility in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0410490703==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0410490703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C863C2.029DD386" This is a multi-part message in MIME format. ------_=_NextPart_001_01C863C2.029DD386 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , Is there a separate RFC for the implementation of extension mobility in SIP Uas ? If not, is it possible to achieve that ? Please provide your valuable suggestions and feedbacks. Thanks & Regards, Anisha ------_=_NextPart_001_01C863C2.029DD386 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Extension mobility in SIP

Hi ,

 Is there a separate = RFC for the implementation of extension mobility in SIP Uas ? If not, is = it possible to achieve that ?

 Please provide your = valuable suggestions and feedbacks.

Thanks & = Regards,
Anisha

------_=_NextPart_001_01C863C2.029DD386-- --===============0410490703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0410490703==-- From sip-bounces@ietf.org Thu Jan 31 00:29:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKRys-0001vt-52; Thu, 31 Jan 2008 00:28:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKRyq-0001vS-8f for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 00:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKRyp-0001vF-Un for sip@ietf.org; Thu, 31 Jan 2008 00:28:55 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKRyp-0003At-Gm for sip@ietf.org; Thu, 31 Jan 2008 00:28:55 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m0V5Sotv024833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Jan 2008 23:28:52 -0600 In-Reply-To: <9A1299C7A40D7447A108107E951450CA05ACF56E@MAIL-TVM.tvm.nestgroup.net> References: <9A1299C7A40D7447A108107E951450CA05ACF56E@MAIL-TVM.tvm.nestgroup.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <421CAD6D-DDF5-4650-85E7-B4C283B1553C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Extension mobility in SIP Date: Wed, 30 Jan 2008 23:28:44 -0600 To: Anisha Kumar X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jan 30, 2008, at 10:30 PM, Anisha Kumar wrote: > Hi , > > Is there a separate RFC for the implementation of extension > mobility in SIP Uas ? If not, is it possible to achieve that ? > What do you mean "extension mobility"? Are you thinking of the use case where a SIP user agent is moving around and occasionally changes its IP address and point of attachment to the Internet? Do you expect call continuity in such a case, quick recovery of the call afterward, or call drop? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 01:27:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKSto-0007Xw-Ej; Thu, 31 Jan 2008 01:27:48 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKStm-0007Qa-FZ for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 01:27:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKStl-0007NO-U6 for sip@ietf.org; Thu, 31 Jan 2008 01:27:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKStl-0003w0-Cj for sip@ietf.org; Thu, 31 Jan 2008 01:27:45 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Jan 2008 22:27:44 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0V6Ri3G002180; Wed, 30 Jan 2008 22:27:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0V6RiZx012892; Thu, 31 Jan 2008 06:27:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 22:27:44 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.95.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 22:27:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 31 Jan 2008 00:27:42 -0600 To: Dean Willis , Anisha Kumar From: "James M. Polk" Subject: Re: [Sip] Extension mobility in SIP In-Reply-To: <421CAD6D-DDF5-4650-85E7-B4C283B1553C@softarmor.com> References: <9A1299C7A40D7447A108107E951450CA05ACF56E@MAIL-TVM.tvm.nestgroup.net> <421CAD6D-DDF5-4650-85E7-B4C283B1553C@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jan 2008 06:27:43.0766 (UTC) FILETIME=[63243B60:01C863D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1058; t=1201760864; x=1202624864; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Extension=20mobility=20in=20SIP |Sender:=20; bh=a9MvKzEBXHn/3gr7VpxcH4DArCkWx9MZm823RgL+WoY=; b=SsfJhYxwbuNEOVd/H8WxB8/qw5BYjXfEmi0yT7dhi4b3TMmSYdgUlWWT+A UkhFk2HXjTHEeJsFTZxmSsUObHXuR8fkTXjMHqLOOLE9/SyEuGGHWXgSnna8 U3Z7QkmGTS; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:28 PM 1/30/2008, Dean Willis wrote: >On Jan 30, 2008, at 10:30 PM, Anisha Kumar wrote: > >>Hi , >> >> Is there a separate RFC for the implementation of extension >>mobility in SIP Uas ? If not, is it possible to achieve that ? >What do you mean "extension mobility"? Are you thinking of the use >case where a SIP user agent is moving around and occasionally changes >its IP address and point of attachment to the Internet? Do you expect >call continuity in such a case, quick recovery of the call afterward, >or call drop? A lot of times, 'extension mobility' means the number to call a phone (UA) changes based on who logged (or registered) onto it -- which is very different that what is above. >-- >Dean > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 04:04:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKVLF-00046T-Ih; Thu, 31 Jan 2008 04:04:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKVLD-000467-St for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 04:04:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKVLD-00045z-DI for sip@ietf.org; Thu, 31 Jan 2008 04:04:15 -0500 Received: from nestgroup.net ([203.200.157.75] helo=mx-01.nestgroup.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKVL6-0006SE-NH for sip@ietf.org; Thu, 31 Jan 2008 04:04:15 -0500 Received: from MAIL-TVM.tvm.nestgroup.net ([192.168.192.74]) by mx-01.nestgroup.net (8.13.1/8.13.1) with ESMTP id m0V9BSfI023024 for ; Thu, 31 Jan 2008 14:41:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Extension mobility in SIP Date: Thu, 31 Jan 2008 14:33:40 +0530 Message-ID: <9A1299C7A40D7447A108107E951450CA05AF8A98@MAIL-TVM.tvm.nestgroup.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Extension mobility in SIP Thread-Index: Achj0mpNNa8byj0CTCGXtkVxNHVKRQAFXyXg From: "Anisha Kumar" To: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on MX-01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 The Extension Mobility feature dynamically configures a phone according to the current user. Once a user logs in, the phone adopts the user individual user default device profile information, including line numbers, speed dials, services links, and other user-specific properties of a phone. For example, when user A occupies a desk and logs in to the phone, her directory number(s), services, speed dials, and other properties appear on that phone; but when user B uses the same desk at a different time, his information appears. Hope this is clear. How is this achieved in SIP ? Thanks & Regards, Anisha -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Thursday, January 31, 2008 11:58 AM To: Dean Willis; Anisha Kumar Cc: sip@ietf.org Subject: Re: [Sip] Extension mobility in SIP At 11:28 PM 1/30/2008, Dean Willis wrote: >On Jan 30, 2008, at 10:30 PM, Anisha Kumar wrote: > >>Hi , >> >> Is there a separate RFC for the implementation of extension mobility >>in SIP Uas ? If not, is it possible to achieve that ? >What do you mean "extension mobility"? Are you thinking of the use case >where a SIP user agent is moving around and occasionally changes its IP >address and point of attachment to the Internet? Do you expect call=20 >continuity in such a case, quick recovery of the call afterward, or=20 >call drop? A lot of times, 'extension mobility' means the number to call a phone (UA) changes based on who logged (or registered) onto it -- which is very different that what is above. >-- >Dean > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 07:57:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYz7-0003q4-SU; Thu, 31 Jan 2008 07:57:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKYz5-0003pJ-NR for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 07:57:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYz5-0003oP-CB for sip@ietf.org; Thu, 31 Jan 2008 07:57:39 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKYz3-0003gp-Qt for sip@ietf.org; Thu, 31 Jan 2008 07:57:39 -0500 X-IronPort-AV: E=Sophos;i="4.25,285,1199682000"; d="scan'208";a="85105018" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2008 07:57:37 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0VCvbT1023529; Thu, 31 Jan 2008 07:57:37 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0VCvW7C029065; Thu, 31 Jan 2008 12:57:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 07:57:31 -0500 Received: from [10.86.241.91] ([10.86.241.91]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 07:57:31 -0500 Message-ID: <47A1C5C1.3090401@cisco.com> Date: Thu, 31 Jan 2008 07:57:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Anisha Kumar Subject: Re: [Sip] Extension mobility in SIP References: <9A1299C7A40D7447A108107E951450CA05AF8A98@MAIL-TVM.tvm.nestgroup.net> In-Reply-To: <9A1299C7A40D7447A108107E951450CA05AF8A98@MAIL-TVM.tvm.nestgroup.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2008 12:57:31.0777 (UTC) FILETIME=[D77B7F10:01C86408] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2564; t=1201784257; x=1202648257; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Extension=20mobility=20in=20SIP |Sender:=20 |To:=20Anisha=20Kumar=20; bh=R8BOTeWIcdmCA6JG5bNOvmZfUMwp4Xe8T20x2NXJl38=; b=PJXAFzMI9pahoTvVBpde2q8vWMMSOv3KCwVCrfJe0eXhj3sJTYL08KmLja RFix0FjkL+PpGeA1bVhfmFsu6AUARu11sCsX5VDhfiZMbdHBErzbMOdXppOe LD3UedITLk; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is largely not a sip question. The UA can register with any AOR (phone number) it wants after some local conversation with the user determine what that AOR should be. Paul Anisha Kumar wrote: > Hi, > > The Extension Mobility feature dynamically configures a phone according > to the current user. Once a user logs in, the phone adopts > the user individual user default device profile information, including > line numbers, speed dials, services links, and other user-specific > properties of a phone. > > For example, when user A occupies a desk and logs in to the phone, her > directory number(s), services, speed dials, and other properties appear > on that phone; but when user B uses the same desk at a different time, > his information appears. > > Hope this is clear. How is this achieved in SIP ? > > Thanks & Regards, > Anisha > > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, January 31, 2008 11:58 AM > To: Dean Willis; Anisha Kumar > Cc: sip@ietf.org > Subject: Re: [Sip] Extension mobility in SIP > > At 11:28 PM 1/30/2008, Dean Willis wrote: > >> On Jan 30, 2008, at 10:30 PM, Anisha Kumar wrote: >> >>> Hi , >>> >>> Is there a separate RFC for the implementation of extension mobility > >>> in SIP Uas ? If not, is it possible to achieve that ? >> What do you mean "extension mobility"? Are you thinking of the use case > >> where a SIP user agent is moving around and occasionally changes its IP > >> address and point of attachment to the Internet? Do you expect call >> continuity in such a case, quick recovery of the call afterward, or >> call drop? > > A lot of times, 'extension mobility' means the number to call a phone > (UA) changes based on who logged (or registered) onto it -- which is > very different that what is above. > > >> -- >> Dean >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@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@cs.columbia.edu for questions on current sip > Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 08:06:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKZ77-0002yb-L7; Thu, 31 Jan 2008 08:05:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKZ76-0002yG-2Y for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 08:05:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKZ75-0002xw-Cq for sip@ietf.org; Thu, 31 Jan 2008 08:05:55 -0500 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKZ74-0001wC-Lv for sip@ietf.org; Thu, 31 Jan 2008 08:05:55 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1JKZ7D-0004Og-2h; Thu, 31 Jan 2008 05:06:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Extension mobility in SIP Date: Thu, 31 Jan 2008 05:05:46 -0800 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C01119B22@sea02-mxc01.citel.com> In-reply-to: <47A1C5C1.3090401@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Extension mobility in SIP Thread-Index: AchkCMckwyG070J8QwStexagsOPzsAAAQ9rQ References: <9A1299C7A40D7447A108107E951450CA05AF8A98@MAIL-TVM.tvm.nestgroup.net> <47A1C5C1.3090401@cisco.com> From: "Steve Langstaff" To: "Paul Kyzivat" , "Anisha Kumar" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Or maybe it's a SIPPING config framework question, after some local conversation? http://tools.ietf.org/html/draft-ietf-sipping-config-framework-14 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 31 January 2008 12:58 > To: Anisha Kumar > Cc: sip@ietf.org > Subject: Re: [Sip] Extension mobility in SIP >=20 > This is largely not a sip question. The UA can register with=20 > any AOR (phone number) it wants after some local conversation=20 > with the user determine what that AOR should be. >=20 > Paul >=20 > Anisha Kumar wrote: > > Hi, > >=20 > > The Extension Mobility feature dynamically configures a phone=20 > > according to the current user. Once a user logs in, the=20 > phone adopts=20 > > the user individual user default device profile=20 > information, including=20 > > line numbers, speed dials, services links, and other user-specific=20 > > properties of a phone. > >=20 > > For example, when user A occupies a desk and logs in to the=20 > phone, her=20 > > directory number(s), services, speed dials, and other properties=20 > > appear on that phone; but when user B uses the same desk at a=20 > > different time, his information appears. > >=20 > > Hope this is clear. How is this achieved in SIP ? > >=20 > > Thanks & Regards, > > Anisha > >=20 > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, January 31, 2008 11:58 AM > > To: Dean Willis; Anisha Kumar > > Cc: sip@ietf.org > > Subject: Re: [Sip] Extension mobility in SIP > >=20 > > At 11:28 PM 1/30/2008, Dean Willis wrote: > >=20 > >> On Jan 30, 2008, at 10:30 PM, Anisha Kumar wrote: > >> > >>> Hi , > >>> > >>> Is there a separate RFC for the implementation of extension=20 > >>> mobility > >=20 > >>> in SIP Uas ? If not, is it possible to achieve that ? > >> What do you mean "extension mobility"? Are you thinking of the use=20 > >> case > >=20 > >> where a SIP user agent is moving around and occasionally=20 > changes its=20 > >> IP > >=20 > >> address and point of attachment to the Internet? Do you=20 > expect call=20 > >> continuity in such a case, quick recovery of the call=20 > afterward, or=20 > >> call drop? > >=20 > > A lot of times, 'extension mobility' means the number to=20 > call a phone > > (UA) changes based on who logged (or registered) onto it --=20 > which is=20 > > very different that what is above. > >=20 > >=20 > >> -- > >> Dean > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 10:07:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb0y-00086F-8m; Thu, 31 Jan 2008 10:07:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKb0v-0007dU-Qh for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 10:07:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb0v-0007Uz-4k for sip@ietf.org; Thu, 31 Jan 2008 10:07:41 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKb0t-0007gV-Vw for sip@ietf.org; Thu, 31 Jan 2008 10:07:41 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2008 07:07:39 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0VF7dxA003881; Thu, 31 Jan 2008 07:07:39 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0VF7Nqd006841; Thu, 31 Jan 2008 15:07:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 10:07:24 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 10:07:24 -0500 Message-ID: <47A1E433.9080106@cisco.com> Date: Thu, 31 Jan 2008 10:07:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Steve Langstaff Subject: Re: [Sip] Extension mobility in SIP References: <9A1299C7A40D7447A108107E951450CA05AF8A98@MAIL-TVM.tvm.nestgroup.net> <47A1C5C1.3090401@cisco.com> <0D4E483A0E6E0A46861409E5D6C2011C01119B22@sea02-mxc01.citel.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C01119B22@sea02-mxc01.citel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2008 15:07:24.0132 (UTC) FILETIME=[FC168240:01C8641A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3799; t=1201792059; x=1202656059; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Extension=20mobility=20in=20SIP |Sender:=20; bh=8ysyB4fQpV8fT6IdjDo70n8bBeXV4q9iXyF3ocGB3jg=; b=HREDTF9xK39+Kc44zMYFJskcgbuzhnRbQ50BLWixX37Vc/5cZNn6jcqeIc 2jngKqGAC88o09XjzAhyrPvMRrU/M8LGiJv0KOSrxOcDZSb+Kjy2F7OISMxX ie5ycDfbpWF748FTCVuV6PShyTOA1I3ql4jFYbzey83qXlqcNTqnQ=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Or, it could be a matter of using the config framework first, discovering that a local conversation is needed to determine identity, then a local conversation, then more config framework, then registration. But AFAIK there is no guidance on what might be in a configuration that would kick that off. Paul Steve Langstaff wrote: > Or maybe it's a SIPPING config framework question, after some local > conversation? > > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-14 > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 31 January 2008 12:58 >> To: Anisha Kumar >> Cc: sip@ietf.org >> Subject: Re: [Sip] Extension mobility in SIP >> >> This is largely not a sip question. The UA can register with >> any AOR (phone number) it wants after some local conversation >> with the user determine what that AOR should be. >> >> Paul >> >> Anisha Kumar wrote: >>> Hi, >>> >>> The Extension Mobility feature dynamically configures a phone >>> according to the current user. Once a user logs in, the >> phone adopts >>> the user individual user default device profile >> information, including >>> line numbers, speed dials, services links, and other user-specific >>> properties of a phone. >>> >>> For example, when user A occupies a desk and logs in to the >> phone, her >>> directory number(s), services, speed dials, and other properties >>> appear on that phone; but when user B uses the same desk at a >>> different time, his information appears. >>> >>> Hope this is clear. How is this achieved in SIP ? >>> >>> Thanks & Regards, >>> Anisha >>> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Thursday, January 31, 2008 11:58 AM >>> To: Dean Willis; Anisha Kumar >>> Cc: sip@ietf.org >>> Subject: Re: [Sip] Extension mobility in SIP >>> >>> At 11:28 PM 1/30/2008, Dean Willis wrote: >>> >>>> On Jan 30, 2008, at 10:30 PM, Anisha Kumar wrote: >>>> >>>>> Hi , >>>>> >>>>> Is there a separate RFC for the implementation of extension >>>>> mobility >>>>> in SIP Uas ? If not, is it possible to achieve that ? >>>> What do you mean "extension mobility"? Are you thinking of the use >>>> case >>>> where a SIP user agent is moving around and occasionally >> changes its >>>> IP >>>> address and point of attachment to the Internet? Do you >> expect call >>>> continuity in such a case, quick recovery of the call >> afterward, or >>>> call drop? >>> A lot of times, 'extension mobility' means the number to >> call a phone >>> (UA) changes based on who logged (or registered) onto it -- >> which is >>> very different that what is above. >>> >>> >>>> -- >>>> Dean >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@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@cs.columbia.edu for questions on current sip Use >>> sipping@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@cs.columbia.edu for questions on current sip >> Use sipping@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@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 13:50:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKeUe-0003r6-Mh; Thu, 31 Jan 2008 13:50:36 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JKeUb-0003nY-0r for sip-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 13:50:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKeUa-0003nN-N4; Thu, 31 Jan 2008 13:50:32 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKeUa-0004mC-3G; Thu, 31 Jan 2008 13:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 10BE43289E; Thu, 31 Jan 2008 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JKeU5-00073K-VJ; Thu, 31 Jan 2008 13:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 31 Jan 2008 13:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-consent-framework-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Framework for Consent-based Communications in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-sip-consent-framework-04.txt Pages : 32 Date : 2008-01-31 The Session Initiation Protocol (SIP) supports communications for several services, including, real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification, and DoS (Denial of Service) attacks. This document identifies a framework for consent- based communications in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-consent-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-consent-framework-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-31134713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-consent-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-consent-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-31134713.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jan 31 21:57:37 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9843A6823; Thu, 31 Jan 2008 21:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ded5gqOX-vOM; Thu, 31 Jan 2008 21:57:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB4B3A680F; Thu, 31 Jan 2008 21:57:36 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A328D3A67EA for ; Thu, 31 Jan 2008 21:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJlqAwUOoA0K for ; Thu, 31 Jan 2008 21:57:34 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EC7893A67D0 for ; Thu, 31 Jan 2008 21:57:33 -0800 (PST) Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m115x60w014297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 31 Jan 2008 23:59:07 -0600 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <5552F10A-EEE3-42A9-84BA-71962B77C83B@softarmor.com> To: IETF SIP List From: Dean Willis Date: Thu, 31 Jan 2008 23:59:03 -0600 X-Mailer: Apple Mail (2.753) Subject: [Sip] New ABNF RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Those of you submitting drafts that define syntax using ABNF should probably now be referencing RFC 5234 instead of whatever it was last week. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jan 31 22:50:18 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DAC63A6850; Thu, 31 Jan 2008 22:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR4b8F3s5T6N; Thu, 31 Jan 2008 22:50:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F9B3A6833; Thu, 31 Jan 2008 22:50:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93283A683E for ; Thu, 31 Jan 2008 22:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va4yXIAtb87P for ; Thu, 31 Jan 2008 22:50:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D81543A6833 for ; Thu, 31 Jan 2008 22:50:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,289,1199692800"; d="scan'208";a="10926966" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2008 22:51:49 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m116pnxN009688; Thu, 31 Jan 2008 22:51:49 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id m116pn1l012473; Fri, 1 Feb 2008 06:51:49 GMT From: Cullen Jennings To: Dean Willis In-Reply-To: <5552F10A-EEE3-42A9-84BA-71962B77C83B@softarmor.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5552F10A-EEE3-42A9-84BA-71962B77C83B@softarmor.com> Message-Id: <15953304-274E-428C-B110-FCD5508EA1B7@cisco.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 31 Jan 2008 22:51:06 -0800 X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF SIP List Subject: Re: [Sip] New ABNF RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org And a free beer for anyone who can figure out what of relevance changed from 4234 to this :-) On Jan 31, 2008, at 9:59 PM, Dean Willis wrote: > > Those of you submitting drafts that define syntax using ABNF should > probably now be referencing RFC 5234 instead of whatever it was last > week. > > -- > Dean > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From bwebb@unimpeks.com Thu Jan 31 22:57:31 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4C93A6844 for ; Thu, 31 Jan 2008 22:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 29.734 X-Spam-Level: ***************************** X-Spam-Status: Yes, score=29.734 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134, TVD_RCVD_IP=1.931] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 2.1 TVD_FINGER_02 TVD_FINGER_02 * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 96] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 96] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [121.247.0.93 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axVzBpMtqHaZ for ; Thu, 31 Jan 2008 22:57:31 -0800 (PST) Received: from 121.247.0.93.Ahmedabad-dynamic-bb.vsnl.net.in (unknown [121.247.0.93]) by core3.amsl.com (Postfix) with SMTP id 32BF43A683F for ; Thu, 31 Jan 2008 22:57:28 -0800 (PST) Received: from arkj ([210.106.132.233]) by 121.247.0.93.Ahmedabad-dynamic-bb.vsnl.net.in with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Feb 2008 12:29:06 +0530 Message-ID: <000e01c8649f$efd328f0$e9846ad2@arkj> From: To: Subject: ***SPAM*** 29.734 (5) I Love You Because Date: Fri, 1 Feb 2008 12:29:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Hugging My Pillow http://89.37.39.244/ From to11@volition-inc.com Thu Jan 31 22:58:38 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC123A6840 for ; Thu, 31 Jan 2008 22:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 37.599 X-Spam-Level: ************************************* X-Spam-Status: Yes, score=37.599 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 24.8.215.93] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [121.247.0.93 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7osqChCbcWy2 for ; Thu, 31 Jan 2008 22:58:38 -0800 (PST) Received: from 121.247.0.93.Ahmedabad-dynamic-bb.vsnl.net.in (unknown [121.247.0.93]) by core3.amsl.com (Postfix) with SMTP id 2C9F93A67E1 for ; Thu, 31 Jan 2008 22:58:36 -0800 (PST) Received: from [187.60.227.184] (helo=rwwkz) by 121.247.0.93.Ahmedabad-dynamic-bb.vsnl.net.in with smtp (Exim 4.62 (FreeBSD)) id 1JLYw1-0004WK-Ch; Fri, 1 Feb 2008 12:33:37 +0530 Message-ID: <47A2C37F.1060007@volition-inc.com> Date: Fri, 1 Feb 2008 12:30:15 +0530 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sip-archive@lists.ietf.org Subject: ***SPAM*** 37.599 (5) You're In My Thoughts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eternity of Your Love http://24.8.215.93/