Subject: RE: [Sip] Call transfer using SIP

From: [email-masked]
Date: Wed, 4 Feb 2004 16:24:01 -0000

This vagueness makes it very difficult to engineer a telephony solution
which interoperates with other vendors equipment. In the telephony arena
getting call transfer right is of fundamental importance. A simple document
titled "Call transfer in SIP" would suffice in de-mystifying this area.

-----Original Message-----
From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
Sent: 04 February 2004 16:10
To: Paul Kyzivat
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Call transfer using SIP

Hi folks,
   It's an interesting point.
Paul's comment seems to be "there are many different ways of skinning a 
cat, and the
only normative definition is of the knife".
The IETF defines the details of knife behaviour, and it's up to 
everyone else to sort
out how to use it for their purpose.

My understanding is that the IETF (and the SIP WG in particular) will 
not produce normative
definitions of these (or any other) teleservices, only definitions of 
protocol elements that
might be used for these (or other) purposes.
SIPPING will consider such services and decide on the protocol elements 
they think are needed
(that don't exist already) and then SIP grinds through the details.

Thus the only teleservice examples are in the service-examples document 
(collected together
as a convenience), these are non-normative, and there will never BE 
normative teleservice
definitions produced by these groups. Is this correct?

all the best,
   Lawrence

On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:

>
>
> [email-masked] wrote:
>> Could somebody please confirm that if I am writing a call control 
>> application offering call hold and transfer then the definitive 
>> document to follow is draft-ietf-sipping-service-examples-05.txt?
>
> No. The *definitive* document is RFC3261 and related documents. The 
> details of call control are derivative from that in somewhat the same 
> way the much of physics is derivative from F=MA.
>
> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an 
> *example*. It is not normative.
>
> However, that draft is certainly helpful and educational. You would do 
> well to understand what is in there before completing your task.
>
> 	Paul
>
>
> _______________________________________________
> 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
>

-- 
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential
to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create
or
change any contractual relationship.

For Aculab's privacy policy and E-Mail disclaimer, Click Here :
http://www.aculab.com/company/legal_notice.htm.

---

From: Alex Audu <[email-masked]>
Date: Wed, 04 Feb 2004 13:39:37 -0600

See also:

http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.txt

The following, another pertinent draft,  seems to have expired for some
reason:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-02.txt

Alex.

[email-masked] wrote:

>
>
> This vagueness makes it very difficult to engineer a telephony
> solution which interoperates with other vendors equipment. In the
> telephony arena getting call transfer right is of fundamental
> importance. A simple document titled "Call transfer in SIP" would
> suffice in de-mystifying this area.
>
> The information contained in this e-mail and any attachments is
> confidential to
> permission. This communication is for information only and shall not
> create or

---

From: "Rajesh Khandewale" <[email-masked]>
Date: Wed, 4 Feb 2004 14:00:59 -0800

I have a question about the proxy behavior under the following scenario,
could someone please provide a clarification.

1. UAC sends an INVITE via proxy.
2. Proxy responds back with 100 trying message to UAC and forwards INVITE to
UAS.
3. UAS sends 200 OK which is relayed by the proxy to UAC.
4. UAC sends an ACK which is being processed by the proxy to be forwarded to
the UAS.
** Here ACK has sequence number 1
5. UAC sends another INVITE and incidentally this gets forwarded to the UAS
before the ACK from previous INVITE by the proxy.
** Here INVITE has sequence number 2
6. Since UAS did not receive the ACK for previous INVITE (nor did it
received CANCEL/BYE), but received another INVITE with same Call-ID etc. it
throws a "500 Internal Server Error" error.

According to RFC 3261, the UAS behavior to throw a "500 Internal Server
Error" is correct. But I am not sure about the proxy behavior here, could
not be clearly figured out of 3261.

Is proxy supposed to correlate all the messages based on the sequence number
and call-id and essentially send an ACK before sending out second INVITE. Or
they are completely different transactions and this is a normal proxy
behavior.

Thanks,

Rajesh.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 18 Feb 2004 05:44:35 -0800

> they are completely different transactions and this is a normal proxy

They are completely different transactions.  The proxy just forwards 
the 500 response normally.

In future, please direct these kinds of requests to 
[email-masked]

thanks,
-rohan