headers
somesh s | 1 Mar 2005 05:40
Picon
Favicon

Re: Section 17.1.1.2, RFC 3261

Ajay,

Please correct me if I am wrong. In the *proceeding*
state how long the uA has to wait is implementation
dependent.

With regards
Somesh S. Shanbhag

--- Idnani Ajaykumar-AIDNANI1
<Ajaykumar.Idnani <at> motorola.com> wrote:

> Hi All,
>  
> I was reading section 17.1.1.2 of RFC 3261 and I had
> some basic questions, so I thought I will ask the
> experts.
>  
> 1. What is the UAC supposed to do when it is in the
> Proceeding state and it does not receive any final
> response? The text in section 17.1.1.2 does talk
> about this case. Also when I look at the flow in
> Firgure 5, there seems to be no timer attached to
> get out of the 'Proceeding' state. There is one
> attached to 'Calling' (Timer B) and 'Completed'
> (Timer D) states, but none to 'Proceeding' state. So
> are we saying that once you get into Proceeding
> state and the other end fails for some reason, the
> UAC is stuck.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
somesh s | 1 Mar 2005 05:45
Picon
Favicon

Re: Section 17.1.1.2, RFC 3261

Ajay,

This issue is discussed recently in one of the
threads.
Please refer to this link.

http://lists.cs.columbia.edu/pipermail/sip-implementors/2005-February/thread.html
with subject as "Ringing time -- Endpoint or Network".

With regards
Somesh S. Shanbhag

--- Idnani Ajaykumar-AIDNANI1
<Ajaykumar.Idnani <at> motorola.com> wrote:

> Hi All,
>  
> I was reading section 17.1.1.2 of RFC 3261 and I had
> some basic questions, so I thought I will ask the
> experts.
>  
> 1. What is the UAC supposed to do when it is in the
> Proceeding state and it does not receive any final
> response? The text in section 17.1.1.2 does talk
> about this case. Also when I look at the flow in
> Firgure 5, there seems to be no timer attached to
> get out of the 'Proceeding' state. There is one
> attached to 'Calling' (Timer B) and 'Completed'
> (Timer D) states, but none to 'Proceeding' state. So
> are we saying that once you get into Proceeding
(Continue reading)

Permalink | Reply | 0 comments |
headers
somesh s | 1 Mar 2005 09:53
Picon
Favicon

About SDP recvonly

Hi All,

Take the scenario:

   UA1 --------------------> UA2

if UA1 sends some codec in recvonly mode then
according   
to RFC 3264, UA2 has to reply with sendonly. 

But in case UA2, prior to offer, knows that it cannot
send the offered media stream (rather it also wants
"recvonly"), how it has to reply?
sendonly with port as zero?...

Please correct me if I am wrong.

Thanks,
Somesh S. 

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
Permalink | Reply | 3 comments |
headers
ljzhang | 1 Mar 2005 10:17

Question About ACK

hi,

Looking at the following scenerio:
UAC's URI is 0 <at> 59.64.159.148
UAS's URI is 2 <at> 59.64.159.126
Proxy is responsible for the domain "59.64.159.126"

UAC sends ACK to Proxy. The ACK method's content is as following:

ACK sip:2 <at> 59.64.159.126:5060 SIP/2.0
Via: SIP/2.0/udp 192.168.2.14:5060;branch=1000
From: <sip:0 <at> 59.64.159.148>;tag=16
To: <sip:2 <at> 59.64.159.126>
Call-ID: [call_id]
Cseq: 1 ACK
Contact: <sip:0 <at> 59.64.159.148:5060>
Max-Forwards: 2
Route: <sip:2 <at> 59.64.159.126:5060;transport=udp>
Subject: Performance Test
Content-Length: 0

Why doesn't proxy send ACK to 59.64.159.126:5060, but send ACK back to 59.64.159.148:5060?

Thanks a million!
 				

　　　　　　　　ljzhang
　　　　　　　　xueyou38 <at> 163.com
　　　　　　　　　　2005-03-01
(Continue reading)

Permalink | Reply | 1 comment |
headers
Banibrata Dutta | 1 Mar 2005 10:22
Picon

RE: Question About ACK

Can you post your "200 OK" too ?

-bd 

> -----Original Message-----
> From: sip-implementors-bounces <at> cs.columbia.edu 
> [mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of ljzhang
> Sent: Tuesday, March 01, 2005 2:48 PM
> To: sip-implementors <at> cs.columbia.edu
> Subject: [Sip-implementors] Question About ACK
> 
> hi,
> 
> Looking at the following scenerio:
> UAC's URI is 0 <at> 59.64.159.148
> UAS's URI is 2 <at> 59.64.159.126
> Proxy is responsible for the domain "59.64.159.126"
> 
> UAC sends ACK to Proxy. The ACK method's content is as following:
> 
> ACK sip:2 <at> 59.64.159.126:5060 SIP/2.0
> Via: SIP/2.0/udp 192.168.2.14:5060;branch=1000
> From: <sip:0 <at> 59.64.159.148>;tag=16
> To: <sip:2 <at> 59.64.159.126>
> Call-ID: [call_id]
> Cseq: 1 ACK
> Contact: <sip:0 <at> 59.64.159.148:5060>
> Max-Forwards: 2
> Route: <sip:2 <at> 59.64.159.126:5060;transport=udp>
> Subject: Performance Test
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tamar Barzuza | 1 Mar 2005 12:55
Favicon

mistake in the Tel-Uri syntax

Hi,

The BNF of Tel-Uri as described in RFC 3966 defines the isdn sub-address
parameter as follows:

isdn-subaddress  = ";isub=" 1*uric

uric                    = reserved / unreserved / pct-encoded

reserved             = ";" / "/" / "?" / ":" / " <at> " / "&" / "=" / "+" /
"$" / ","

But this implies that the isub parameter can contain a semicolon, which
is used to distinguish between parameters. For example, the following
tel-uri can be interpreted in different ways:

tel:+97235451122;isub=Israel;exmpl=ex

Either "Israel;exmpl=ex" is the value of the isub parameter, or "Israel"
is the value of the isub parameter and "exmpl" is the name of an extra
parameter.

Thanks,

Tamar Barzuza.
Permalink | Reply | 0 comments |
headers
tinbarajan | 1 Mar 2005 13:28

Response exceeding the maximum transmission unit


Hi,

      UAS receives a request  via UDP ( sent-protocol in via is UDP ).
      The response to be sent has big body and exceeding the maximum
transmission unit.
      whether UAS can send the response via TCP  ?

Regards,
Thangarajan.

***********************  HSS-Private   ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
Permalink | Reply | 5 comments |
headers
Markus Hofmann | 1 Mar 2005 13:50
Picon

Re: Section 17.1.1.2, RFC 3261

Hi  Ajay,

in my understanding you have only two possibilities to finish this situation.

After TimerA is stopped, TimerB lost its control functionality. If Timer B expires no state will change.

The first possibility is that the user from UAC stopps the situation by sending a CANCEL (hanging up if a
phone). UAS will response to the CANCEL with a 200 OK and a 487 Request Terminated for the INVITE. UAC
answers with an ACK.

By the other possiblity there must be a proxy between. If Timer C expires the proxy sends a 408 to the UAC which
answers with an ACK and the proxy sends a CANCEL to the UAS. The behaviour of the UAS is the same as above, only
the proxy is answering now with an ACK. 

I think this are the only two possiblities.

Greeting

Markus

Idnani Ajaykumar-AIDNANI1 <Ajaykumar.Idnani <at> motorola.com> schrieb am 28.02.05 20:08:50:
> 
> Hi All,
>  
> I was reading section 17.1.1.2 of RFC 3261 and I had some basic questions, so I thought I will ask the experts.
>  
> 1. What is the UAC supposed to do when it is in the Proceeding state and it does not receive any final
response? The text in section 17.1.1.2 does talk about this case. Also when I look at the flow in Firgure 5,
there seems to be no timer attached to get out of the 'Proceeding' state. There is one attached to 'Calling'
(Timer B) and 'Completed' (Timer D) states, but none to 'Proceeding' state. So are we saying that once you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 1 Mar 2005 14:36
Picon
Favicon

Re: About SDP recvonly

Somesh,

UA2 need not answer with recvonly - it may answer with 'inactive'. While 
UA2 could respond with port=0 that suggests that it doesn't want to use 
the medium at all. After responding with inactive, it could send another 
offer with recvonly, or it could wait and see if UA1 does that.

There are quite a lot of options here, and no obviously best one.

	Paul

somesh s wrote:
> Hi All,
> 
> Take the scenario:
> 
>    UA1 --------------------> UA2
>    
> if UA1 sends some codec in recvonly mode then
> according   
> to RFC 3264, UA2 has to reply with sendonly. 
> 
> But in case UA2, prior to offer, knows that it cannot
> send the offered media stream (rather it also wants
> "recvonly"), how it has to reply?
> sendonly with port as zero?...
> 
> Please correct me if I am wrong.
> 
> Thanks,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Biplab Chattopadhyay | 1 Mar 2005 14:38
Picon
Favicon

Deciding transport protocol to use to a subscriber

Hi,
  Can anybody tell me how a B2BUA server can decide
which transport protocol (UDP/TCP) to use to a
subscriber in a registration session, based on the
Register message sent by him.  Taking in consideration
that the Register message might have come through some
intermediate proxies. Also, how this decision is
effected by the presense of Path header in the
message.
  RFC tells to try for TCP if the message crosses some
length and revert back to UDP if it fails.  But it
will be good if we can extract the transport supported
by a UA while it registers.  
  Waiting for responses.

Thanks and regards,
Biplab.

=====
================================== 
Biplab Chattopadhyay
Senior Software Engineer
Motorola, Bangalore
Mobile # 9845220226
Home # 080-23637666
Office # 080-26016274

		
__________________________________ 
Do you Yahoo!?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane