Subject: Re:[Sipping] Opening a discussion on Multiple Path Retry

From: <[email-masked]>
Date: Mon, 19 Nov 2007 15:39:21 +0530

Hi Dale,

I think this is a very good topic which needs discussion.

A proxy is considered to be a constitute of UAC and UAS, so it is very
difficult to distinguish the exsisting Response codes received are from
a proxy or the end UA.

We cannot tell in a network, whether the response comes from the end UA
or not.
Example in a case of interworking ua1-sip1-isup-sip2-ua2:
When ua1 receives a response(4xx), we cannot tell if it is from end UA,
because end UA is some where down the line And sip2 can also be reached
via different path.

Based on the exsisting implentations already in place, I feel creating
more response codes is more burden.
So instead we can create a new header:(like)Enitysource.
This will be inserted in all the resposne codes. This will have the
values UA/Proxy/token.
Based on that we can have the behaviour on the originating UA.

Example: 480. this response will have : Enitysource: Proxy which
indicates that proxy have added this response.

SIP/2.0 480 Temporarily Unavailable 
Via: SIP/2.0/TLS
ss1.example.com:5061;branch=z9hG4bK83749.2;received=192.0.2.54
Via: SIP/2.0/TLS
client.atlanta.example.com:5061;branch=z9hG4bK74bf9;received=192.0.2.103
From: Alice <sips:[email-masked]>;tag=1234567
To: Bob <sips:[email-masked]>;tag=314756
Call-ID: [email-masked]
CSeq: 1 INVITE
Enitysource: Proxy
Content-Length: 0

>>The problem is, SIP doesn't make it particularly clear whether a call 
>>failed due to some difficulty with transport vs. the call reached the
UA and was actively or passively rejected.
I feel always difficulty with transport gives 408.

I have seen similar problem in the network because the proxy is not
avilable and the calls are failed.
The possible reasons for the call to fail are : Proxy is down,2)
rebooted 3) proxy is overloaded so not accepting new messages.
So I had proposed a Draft for asynchronous service change (fyi) 
http://rfc.netvolante.jp/internet-drafts/draft-sreeram-specify-method-00
.txt

Regards,
Sreeram
----
Sreeram Kanumuri
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2007 9:04 AM
To: [email-masked]
Subject: [Sipping] Opening a discussion on Multiple Path Retry

In my employer's PBX system, we're starting to consider problems that
show up when there are multiple ways of getting a call to the
destination, and we want the PBX to try alternatives only if the first
attempt failed.  The problem is, SIP doesn't make it particularly clear
whether a call failed due to some difficulty with transport vs. the call
reached the UA and was actively or passively rejected.

I've written an I-D to start the discussion of solutions to this
problem:

http://www.ietf.org/internet-drafts/draft-worley-redundancy-response-02.
txt

A new version of I-D, draft-worley-redundancy-response-02.txt has been
successfuly submitted by Dale Worley and posted to the IETF repository.

Filename:        draft-worley-redundancy-response
Revision:        02
Title:           Supporting Multiple Path Routing in the Session
Initiation Protocol (SIP)
Creation_date:   2007-11-18
WG ID:           Independent Submission
Number_of_pages: 9

Abstract:
An increasing number of SIP architectures implement multiple path
routing (MPR), which is the providing of more than one path for a call
to reach a destination user agent (UA).  To implement MPR well, the
proxy which forks a request onto the redundant paths needs to be able to
determine if a fork that failed reached the destination UA and was
rejected by the UA (and so an alternate path should not be tried), or if
the fork failed before reaching the UA (and so an alternate path should
be attempted).  This document is to begin a discussion of strategies for
making this determination.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Steve Langstaff" <[email-masked]>
Date: Mon, 19 Nov 2007 02:28:42 -0800

> From: [email-masked] [mailto:[email-masked]] 

> We cannot tell in a network, whether the response comes from 
> the end UA or not.

> Example: 480. this response will have : Enitysource: Proxy 
> which indicates that proxy have added this response.

Was that response generated by proxy 'sip1' or proxy 'sip2'?

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 16:33:49 +0530

Hi Steve,

>>Was that response generated by proxy 'sip1' or proxy 'sip2'?
well, Here the main purpose is to find if we can use MPR or not.
If it is from Proxy: we will try the second path we have from MPR.
If it is from UA we will not try.

It is very difficult and complex to give the details of Proxy also.
Many Proxies keep adding in the network in our path to destination.
And it is not useful to get those proxy information which we canot use.

Regards,
Sreeram
----
Sreeram Kanumuri
[email-masked]

-----Original Message-----
From: Steve Langstaff [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 3:59 PM
To: Sreeram Kanumuri (WT01 - TES-Mobility & Carrier Infrastructure);
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Opening a discussion on Multiple Path Retry

> We cannot tell in a network, whether the response comes from the end 
> UA or not.