Venkat,
This particular issue is just one of the areas in which re-using a Call-ID
for a new call could cause potential issues. As you're aware, Billy Biggs
has released a new copy of the "SIP Replaces" draft where the re-use of
Call-IDs is allowed. This draft has elicited comments, including some from
yourself, and Billy will be producing a new, updated version shortly.
My colleague, Jonathan Cumming, is about to contact Billy (cc.ing the
mailing list) regarding the re-use of Call-IDs and their discussions will
certainly affect this thread, and possibly the forthcoming draft. With that
in mind, I suggest we wait to see how Jonathan C. and Billy's discussions go
before proceeding.
Please let me know if I can be of help in the meantime,
Regards,
Paul DS.
Paul D.Smith
Voice Networking Group
Data Connection Ltd
Tel: +44 20 8366 1177
Fax: +44 20 8367 8501
Email: [EMAIL PROTECTED]
Web: http://www.dataconnection.com
-----Original Message-----
From: A Venkatraman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 24, 2001 19:51
To: Paul D.Smith
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] REFER and use of Call-ID
Paul
I am trying to understand the issue that you have raised in the paragraph
below -
One potential problem arising from the transfer-04 model is if the call is
then transferred back to the original callee. The second REFER will now
result in a call-leg with the same Call-ID, To and From as the _original_
call-leg which would make them indistinguishable.
In the case of the call being transferred back to the original callee, the
INVITE to the original callee will be seen to be a new call if a BYE was
sent on the original call leg after the first REFER succeeded. If the BYE
is not sent, the INVITE would be seen as a Re-Invite and should work.
Am I understanding the scenario correctly?
Regards,
Venkat
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Paul D.Smith
Sent: Tuesday, July 17, 2001 7:44 AM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] REFER and use of Call-ID
John,
Thanks for the response. Unfortunately I perhaps wasn't clear enough about
my concerns. As you say, identifying the call-leg in the single REFER case
is not an issue because the combination of Call-ID and To and From addresses
will be unique for the two call-legs. My concern is that RFC 2543 reads as
though each Call is associated with _only_ the call-legs resulting from a
single INVITE.
If this interpretation of RFC 2543 is correct, the INVITE resulting from the
REFER processing is a _different_ INVITE and therefore should result in a
different Call. In contrast transfer-04 seems to allow the _new_ INVITE to
create new call-legs within an existing Call.
One potential problem arising from the transfer-04 model is if the call is
then transferred back to the original callee. The second REFER will now
result in a call-leg with the same Call-ID, To and From as the _original_
call-leg which would make them indistinguishable.
This is one example of the sort of issues which arise when new call-legs
result from multiple distinct INVITEs (not re-INVITEs) within a Call. RFC
2543 seems to forbid this, possibly for this very reason.
There is also the minor point that if RFC 2543 and transfer-04 are truely at
odds, it sets a dangerous precendent for SIP "additions" actually violating
the base SIP specification.
What I am looking for is a clarification of RFC 2543 and/or transfer-04
indicating which approach is the correct one and how scenarios such as the
one I've indicated are avoided when using transfer-04.
Thanks,
Paul DS.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 16, 2001 16:47
To: Paul D.Smith; [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] REFER and use of Call-ID
Each call leg at a particular UA is defined by the To, From and Call-ID.
The To header should be different for the Invite to the new leg for the
transfer, so the same Call-ID could be used.
-----Original Message-----
From: Paul D.Smith [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 16, 2001 9:36 AM
To: '[EMAIL PROTECTED]'
Subject: [Sip-implementors] REFER and use of Call-ID
I'm sure this has been worked over before but can someone please shed some
light on the following apparent disconnect regarding Call-ID: between the
"SIP Call Control - Transfer" specification and the base SIP specification?
The base SIP specification says the following about Call-ID.
--- From RFC 2543 ---
6.12 Call-ID
The Call-ID general-header field uniquely identifies a particular invitation
or all registrations of a particular client. Note that a single multimedia
conference can give rise to several calls with different Call-IDs, e.g., if
a user invites a single individual several times to the same (long-running)
conference.
---
This implies that each INVITE (not RE-INVITEs) results in a new Call-ID.
Compare this to the REFER specification, draft-ietf-sip-cc-transfer-04,
where the Refer-to: header can take the following value:
--- From ...transfer-04 ---
Refer-To:
sip:[EMAIL PROTECTED]?Accept-Contact=sip:bobsdesk.biloxi.com&Call-ID=55432@alic
epc.atlanta.com
----
The REFER specification goes on to give examples (4.5.1 and 4.7) of calls
being transferred by issuing new INVITEs, to new partners, using the _same_
Call-ID as the original call which is being transferred.
So my question is how can the two specifications be consistent? It appears
to me that RFC 2543 requires each new INVITE to use a new Call-ID whereas
...transfer-04 allows a new INVITE to reuse an existing Call-ID. What is
the consensus on which interpretation is correct or most widely used?
Thanks in advance for your clarifications,
Paul D.Smith.
> Paul D.Smith
> Voice Networking Group
> Data Connection Ltd
> Tel: +44 20 8366 1177
> Fax: +44 20 8367 8501
> Email: [EMAIL PROTECTED]
> Web: http://www.dataconnection.com
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
