Subject: RE: [SIP] REFER feature with 'replaces' header

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Mon, 12 Mar 2001 10:44:41 -0800

This question is probably not totally relevant to this chain, but
nevertheless, I wanted some clarification...

As I remember it correct, one of the issues with REFER was that the transfer
will not always be successful.... I remember a thread about this 4/5 months
back and think it had to do with Contact/Request URL not always identifying
the end point exactly (like in cases of ACD agents behind firewalls or
something to that effect. My guess is that the modified REFER *still* does
not address this issue. Is my understanding correct??

Thanks.
Venkatesh

-----Original Message-----
From: Suheel Hussain [mailto:[email-masked]]
Sent: Monday, March 12, 2001 10:44 AM
To: Billy Biggs
Cc: SIP List
Subject: Re: [SIP] REFER feature with 'replaces' header

inline:

Billy Biggs wrote:

> Suheel Hussain ([email-masked]):
> 
> 
>> I am in the process of implementin REFER feature on a user-agent. I
>> plan to use 'replaces' header (draft-biggs-sip-replaces-00) in REFER
>> for smooth call-transfer. (Transfer target quitely replaces, its
>> connection with Transferror, with INVITE from Transferee.)
>> 
>> I have following questions regarding REFER with replaces:
>> [...]
>> 2. 'replaces' header specifies only Transferror<->Target call-id to
>>    identify call-leg to be replaced on transfer target. According to
>>    SIP spec, From, To, and call-id specifies a complete call.  Thus,
>>    more than call-id mandatory field are required to specify
>>    transferror-target call.
> 
> 
>   There was some debate internally when we wrote the draft on what
> exactly should be required in the header such that it would be easiest
> to implement and easiest to use.
> 
>   The call-id as a unique key is attractive because it is "very
> unlikely" that two established call legs will share the same call-id.
> Escaping the full to and from headers is a pain, and performing the
> unescaping and compare is easy to screw up (especially if there are
> parameters in the URIs etc).  We wanted to avoid interoperability
> difficulties, even at the cost of messing up transfers in the extremely
> unlikely case.
> 
>   Personally, I think the best compromise is to place in the Replaces
> header the Call-ID, near-tag and far-tag for the call leg.  This cuts

how do you define near-tag and far-tag being?

> down on message size and avoids dangerous compares while still uniquely
> identifying the call.
> 
>   Thoughts?

-- 

Suheel Hussain
[email-masked]
Work # (919) 392-2312

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Suheel Hussain <[email-masked]>
Date: Mon, 12 Mar 2001 14:57:49 -0500

Venkatesh,

please see inline comments:

> not address this issue. Is my understanding correct??

REFER specifies transfer target via a sip URL. This SIP URL should be 
able to identify a unique end-point -- though this end-point could 
have moved to a different terminal. Subsequently the triggered INVITE 
would use this URL to reach transfer-target.

I remember seeing thread on reachability across firewalls. But this 
(reaching across firewall) is independent of REFER.

Hope it helps. Let me know your thoughts and suggestions.

-- 

Suheel Hussain
[email-masked]
Work # (919) 392-2312