Subject: RE: [Sip] Loose Routing draft

From: [email-masked]
Date: Tue, 22 Jan 2002 11:19:00 +0200

Hi Robert!

Comments inline:

cheers,
 Bernie

>-----Original Message-----
>From: ext Robert Sparks [mailto:[email-masked]]
>Sent: 11. January 2002 16:54
>To: Honeisen Bernhard (NET/Helsinki); Robert Sparks; [email-masked]
>Subject: RE: [Sip] Loose Routing draft
>
>
>
>
>> -----Original Message-----
>> From: [email-masked] 
>[mailto:[email-masked]]
>> Sent: Friday, January 11, 2002 7:54 AM
>> To: [email-masked]; [email-masked]
>> Subject: RE: [Sip] Loose Routing draft
>> 
>> 
>> Hi Robert et al.!
>> 
>> Intersting I/D! It looks like, that we have a solution
>> for the problem.
>> 
>> I have a couple of questions/comments:
>> 
>> I assume this new procedure can be applied for initial and
>> subsequent requests. Is this assumention correct?
>
>Yes it can. Note that different policies can be applied to initial
>and subsequent requests (so you could loose-route the initial and
>strict-route subsequents if that's what you wanted to do).

How can a proxy make the difference between an initial INVITE
and a re-INVITE? 
I have a feeling, that checking the To tag is not the best solution.
Neither it is a good solution, if proxies need to keep session state.
What other possibilities are there?
 
>> Is there a requirement, that loose routing is needed in
>> subsequent requests?
>
>There are people that want to be able to do this.
>
>> 
>> What would be the impact, if we allow a local policy
>> (as described in your I/D) for the INITIAL request ONLY,
>> and leave subsequent requests as before (i.e. strict
>> source routing).
>> Or in other words: Apply this local policy for
>> pre-loaded route headers only.
>
>We don't preclude that policy but I don't believe we should
>require it.

I would go one step further, and at least discourage people from
loose-routing _subsequent_ requests (e.g. re-INVIVEs).

>> Therefore we could introduce a new Route parameter, which 
>> informs about, that the Routing can be loose, or has 
>> to be strict.
>> 
>>  e.g. Route: [email-masked]; routing=loose
>>  (or similar)
>
>There's a problem with who knows when to include such an
>indicator. If you are an endpoint, you don't know what
>the service you are trying to use might need to do (unless
>the service has told you through some mechanism like PATH,
>in which case the service can manage its own policy)
>
>> 
>> New proxy implementations would route strict, if no
>> such paramenter present and apply the local policy
>> only of this parameter present.
>> Older proxy implementations would simply ignore this
>> new parameter.
>> 
>> I see the following advantages of my proposal:
>> 
>> - Changes to existing SIP are fewer
>>   (only the new case of pre-loaded route headers
>>   in initial request would be affected)
>>   - more backwards compatibility
>>   - Less new error cases (can apear only during session
>>     first INVITE)
>> 
>> - Pre-loaded Route headers can be defined as
>>   "loose" or as "strict"
>> 
>> 
>> I am looking forward for comments on this proposal!
>> 
>> cheers, 
>>  Bernie
>> 
>> 
>> >-----Original Message-----
>> >From: ext Robert Sparks [mailto:[email-masked]]
>> >Sent: 11. January 2002 6:46
>> >To: [email-masked]
>> >Subject: [Sip] Loose Routing draft
>> >
>> >
>> >I just submitted a draft refining the post I sent
>> >out after IETF52 on the loose routing proposal.
>> >
>> >Until it appears in the archive, you can find it at
>> >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt
>> >or
>> >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html
>> >
>> >
>> >RjS
>> >
>> >_______________________________________________
>> >Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>> >This list is for NEW development of the core SIP Protocol
>> >Use [email-masked] for questions on current sip
>> >Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Lei Liang <[email-masked]>
Date: Tue, 22 Jan 2002 14:52:30 +0000 (GMT)

Hi, guys,
  I see in Megaco the MGC support SDP and SIP. but I don't know how
exactly it works. is there idea to handle this problem in SIP
consideraton?
  I also wondered how SIP is translated to a PSTN handset. is there any
specification in the bis-05?

thanks a lot.
lei

---

From: Sean Olson <[email-masked]>
Date: Tue, 22 Jan 2002 07:29:11 -0800 (PST)

> What other possibilities are there?

The solution you choose will be based on why
you care that this is a re-INVITE. I think that
in almost all cases, if you really care, you
will maintain session state.

> loose-routing _subsequent_ requests (e.g.

I see no reason to do this. Loose routing is all
about local policy. As long as the strict
route is honored, it shouldn't matter what happens
in subsequent requests.

/sean

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 22 Jan 2002 10:12:08 -0800

An MGC function is in part a protocol engine and can support and interwork 
many protocols such as SIP, MEGACO, H.323, LDAP, etc. But the development 
of each protocol is independent so we needn't concern ourselves with it in 
the SIP working group. And the interworking happens within the MGC function 
so that is out of scope here too.