Tina K | 1 Sep 2005 05:57
Picon

3PCC re-connecting scenario

Hi,
we are developing the application for re-connecting parties taken from 2 
different calls. Initially I was thinking about inviting first party with 
no_media SDP, 200-ACK, then re-INVITE B-party with no media, obtain offer, 
re-INVITE A with SDPb. Then A answer with SDP a' which will be sent to B 
within ACK:
<----------INVITE (SDP no_media)
---------> 200
<----------ACK 
----------------->INVITE (no SDP)
<-----------------200 (SDPb)
<---------------INVITE (SDP b)
-------------->200 (SDP a)
-------------------------> ACK (SDP a)
<----------------ACK

Unfortunately:
1. re-INVITE with no_media causes offer in real life (despite RFC 3725). I 
suppose some Media Gateways will send BYE upon reception ACK without an SDP 
anser
2 . ACK (SDP a) - the call may end up by generation a BYE by B-party. 
Let' say I send first INVITE with idisabled media (a=sendonly or inactive) , 
get 200 with SDPa and send ACK. However, the second problem seems to me 
critical.
Any ideas how to avoid ACK with SDP?

Thanks,
Tina
--

-- 
BRs,
(Continue reading)

Neeraj Jain | 1 Sep 2005 06:30

RE: Proxy blocking a provisional response

Please see inline.

Regards,

Neeraj

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Jeroen van
Bemmel
Sent: Thursday, September 01, 2005 3:35 AM
To: sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] Proxy blocking a provisional response

RFC3261 section 16.7 point 5:  [...] "After a final response has been sent
on the server transaction, the following responses MUST be forwarded
immediately:

         -  Any 2xx response to an INVITE request

A stateful proxy MUST NOT immediately forward any other responses."

Does this mean that if a 180 and 200 arrive out-of-order and the proxy
processes the 200 first, it should drop the 180 response?

[Neeraj] Yes. 180 arriving after 2xx should be dropped.

If yes, what happens if the 180 was sent with 100rel?

[Neeraj] As per RFC3262, a UAS must NOT send 2xx response if there is a
(Continue reading)

Parveen Jain | 1 Sep 2005 12:25

Cseq with PRACK and reinvite

Hi All,
  See the scenario:
    A                 B
    ----INVITE-------->        CSeq = 1
    <----RINGING------
    -----PRACK-------->        CSeq = 2
    <----OK(PRACK)----
    <----OK(INVITE)---
    ---ACK(INVITE)---->

     ----ReINVITE----->       CSeq = 3
    <---OK(ReINVITE)---
    ----ACK(ReINVITE)-->
    ----BYE---------->        CSeq = 4

Second Scenario:

    A                 B
    ----INVITE-------->        CSeq = 1
    <----RINGING------
    -----PRACK-------->        CSeq = 2
    <----OK(PRACK)----
    <----OK(INVITE)---
    ---ACK(INVITE)---->
    ----BYE---------->        CSeq = 3

    
Is this behaviour right in terms of Cseq ? Please Comment.

Thanks in Advance.
(Continue reading)

Neeraj Jain | 1 Sep 2005 12:53

RE: Cseq with PRACK and reinvite

Yes. It is correct.

Neeraj Jain
BayPackets Technologies

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Parveen Jain
Sent: Thursday, September 01, 2005 3:56 PM
To: sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] Cseq with PRACK and reinvite

Hi All,
  See the scenario:
    A                 B
    ----INVITE-------->        CSeq = 1
    <----RINGING------
    -----PRACK-------->        CSeq = 2
    <----OK(PRACK)----
    <----OK(INVITE)---
    ---ACK(INVITE)---->

     ----ReINVITE----->       CSeq = 3
    <---OK(ReINVITE)---
    ----ACK(ReINVITE)-->
    ----BYE---------->        CSeq = 4

Second Scenario:

    A                 B
(Continue reading)

Bob Penfield | 1 Sep 2005 13:56
Favicon

Re: clarification of RFC3261 text

No, the UAC should not send a BYE on the remaining early dialogs. If the
request was forked, the proxy that forked the request would have sent CANCEL
to the remaining branches upon receiving the 200-OK. Normally, those
branches would return 487 which the proxy would not pass back to the UAC.
The UAC has no way to know the state of those early dialogs, and it is safe
assume that they were properly cancelled. If a particular early dialog was
not cancelled, the only thing the UAC could possibly see would be a 200-OK
(which the UAC ACKs) confirming the additional dialog. At that point, the
UAC is free to continue that dialog or terminate by sending a BYE.

The UAS does not send BYE on early dialog. The case you site is were the UAS
has sent a 200-OK (confirming the dialog), but has not received the ACK from
the UAC. Thus the BYE is on a confirmed dialog (from the point of view of
the UAS).

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
bpenfield <at> acmepacket.com

----- Original Message ----- 
From: "Jeroen van Bemmel" <jbemmel <at> zonnet.nl>
To: <sip-implementors <at> cs.columbia.edu>
Sent: Wednesday, August 31, 2005 3:52 PM
Subject: [Sip-implementors] clarification of RFC3261 text
(Continue reading)

John Miller | 1 Sep 2005 14:12
Favicon

Click To Dial

Hi All,

Could some one help me get the details for Click To Dial on SIP.When the user Clicks the Link How the server get
the details of the Client (like IP or Username or password) and also whats about the SDP of the client.

Could some one help me on this

Thanks
John Miller

--

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Gyselinck Luc | 1 Sep 2005 15:29

fax transport negotiation in SIP/SDP

Hi all, 
please find below my interpretation of how renegotiation must be done (using REINVITE) for setting up a fax
call, when first a normal voice call was setup.
The below procedure is based on ITU-T T.38 and RFC for SDP and offer/answer.
I like your comments on this description :

Fax transport in SIP networks, where receiving GW supports T38 on top of the VBD.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />A call is setup from
Emitting to receiving Residential GW.

First a voice call is setup, the SDPs do not contain t38 capability. 

Somewhat later, a fax call is detected in receiving GW.

The Receiving GW sends a RE-INVITE, which contains an SDP offer with :
(mandatory) m= line that was present in previous SDP used for voice call (per RFC 3264); the port is set to 0 to
indicate this media is rejected/no longer used
 m= line for t38 using UDPTL
 m= line for t38 using TCP
 m= line for t38 using RTP
 m= line for G711 (VBD)
At least one of the previous m=lines for t38 or VBD is mandatory.  This depends on local configuration/capabilities.

The emitting GW sends an SDP answer with (all m lines that were present in received offer):
 m= line used for voice call with the port is set to 0 
 m= line for t38 using UDPTL; port is set to 0 if rejected
 m= line for t38 using TCP; port is set to 0 if rejected
 m= line for t38 using RTP; port is set to 0 if rejected
 m= line for G711 (VBD) ; port is set to 0 if rejected

(Continue reading)

Andreas Byström | 1 Sep 2005 22:31
Picon

Redirecting information in SIP

Hi!

A service in a SIP network that performs redirection (as a terminating
service for a subscriber), how does it preserve redirecting data?

Example: A calls B, B has in its domain enabled an application server that
will redirect the call to C (not using 302). Application server is a B2B so
it is allowed to change any header. 

In the sipmessage sent to C, is it possible to find the following
information?
- Called Party Address/Number (the number/address of C), address will be in
request uri, but where can a tel URI be stored?
- Calling Party Number/Address (CLI of the original caller, A)
- Original Called Party Number/Addrss (original dialed number/address B)
- Redirecting number/address (the one that made the redirection, B)
- Redirecting counter(how many times this call has been redirected)

In ISUP, there are paramters for these values, how about in SIP? Does
someone know about a draft or RFC where I can find more information? To
solve it I guess I can use SIP-T but is there any other solution?

Regards,
// Andreas
Amarendra Kumar | 1 Sep 2005 23:07
Picon

Re: Click To Dial

HI,

You can reffer to the rfc 3725 sec 10.1. which will clear some of your 
doubts.

On 9/1/05, John Miller <sip_2005 <at> programmer.net> wrote:
> 
> Hi All,
> 
> Could some one help me get the details for Click To Dial on SIP.When the 
> user Clicks the Link How the server get the details of the Client (like IP 
> or Username or password) and also whats about the SDP of the client.
> 
> 
> Could some one help me on this
> 
> 
> Thanks
> John Miller
> 
> --
> ___________________________________________________________
> Sign-up for Ads Free at Mail.com <http://Mail.com>
> http://promo.mail.com/adsfreejump.htm
> 
> 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors <at> cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
(Continue reading)

Pravesh | 2 Sep 2005 06:18
Picon
Favicon

RE: some questions about AOR

Hi Pieere,

As for specifying the port number in X-Lite, you can
specify it as ->
hostname:port as there is no separate field for port
number in X-Lite.

Regards,
Pravesh 

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On
Behalf Of Huibin Pi
Sent: Friday, September 02, 2005 8:28 AM
To: SIP Implementors
Subject: [Sip-implementors] some questions about AOR

Hi!

I am confused by some issues about AOR these days.

I assume that my sip proxy is at HOSTA:PORTA, my
registrar is at
HOSTB:PORTB.

The first question is that which hostname is my AOR's
home domain, HOSTA or
HOSTB?
The second question is that how can I populate my FROM
(Continue reading)


Gmane