headers
vvarun kumar | 2 Jan 2004 07:00
Picon
Favicon

RE:SIP

HI,
I am ArunKumar a software engineer working on SIP.
Please clarify my problem that Iam facing in SIP.
The problem can be small or easy to solve but I am
unable to find solution.

The problem is When I am calling from client to Server
like thru SJPhone software(which resembles Phone in
daily use) in Windows to a software based in Linux.
I am able to recieve trying , ringing message that has
been generated by server but Iam not able to get ACK
or OK message when Iam capturing thru Ethreal
software.

How can I debug and how I can get the OK/ACK message
and when I am calling from other end point I am
getting segementation fault.What could the reason and
How to debug it so that I can get ACK/OK message from
both ends.

Thanks&regards,
Arunkumar.

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
(Continue reading)

Permalink | Reply | 0 comments |
headers
shambhu | 2 Jan 2004 12:47
Favicon

RE: sip standard related query

Hi Chirag,

RFC 2543 has been obsoleted by RFC 3261. rfc 3261 specifies base protocol.
There are some drafts and rfcs extending the same for specific features.

Regards,
Shambhu

Regards,
Shambhu

-----Original Message-----
From: sip-admin <at> ietf.org [mailto:sip-admin <at> ietf.org]On Behalf Of Chirag
Dhruv
Sent: Tuesday, 23 December 2003 4:42 PM
To: sip <at> ietf.org; dromasca <at> avaya.com
Subject: [Sip] sip standard related query

Hi

I am new to SIP and in the process of feasibility study for SIP. I went
through a lot of material on the web, and failed to understand if there
is a common standard for SIP protocol or not. I understand that RFC2543
is the latest starndard available till now, and if I implement that
standard in my device, there is no need to implement other standards.

Looking for a response.

Thanks and Regards,
Chirag.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elwell, John | 2 Jan 2004 17:10
Picon

Use of P-Asserted-Identity in a response

There seem to be some differences of opinion concerning the use of
P-Asserted-Identity (PAI) in a response. In particular, this is delaying the
progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a 200 OK
to convey the connected party identity received from the QSIG network. The
same situation is likely to be encountered when interworking with other
legacy signalling systems.

It is my opinion that PAI can be used in a 200 OK to assert the identity of
the connect party. Moreover, it can be inserted by a gateway UAS and, unless
subject to privacy, can be passed on even to untrusted entities including
the UAC.

My evidence for assuming this is as follows:

1. RFC 3325: In section 5, 2nd paragraph it states:
"If the proxy receives a message (request or response) from a node that it
trusts, it can use the information in the P-Asserted-Identity header field,
if any, as if it had authenticated the user itself."
There is nowhere that forbids the use of P-Asserted-ID in a response,
although there are places in the RFC that mention procedures for a request
without mentioning a response. In many places it talks about "message",
which, according to the text above, means request or response.

2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
calling user, PAI in a 180 response the ringing user and PAI in 200 OK the
user who answered the call. RFC 3325 is supposed to meet the requirement of
RFC3324.

I have seen a number of arguments against the use of PAI in a response:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sanjay Sinha | 2 Jan 2004 19:58
Picon
Favicon

Subscribe dialog and target refresh request

Hi,

For a dialog initiated with SUBSCRIBE, can a subscription for a new 
event on that dialog also be a target refresh request?

- Sanjay.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
David Oran | 3 Jan 2004 20:13
Picon
Favicon

Re: Use of P-Asserted-Identity in a response

These arguments are good ones.
Even if they weren't good I'd still be in favor of what John proposes, 
because it's eminently reasonable and provides desperately needed 
functionality for which we currently have no alternative machinery.

Dave.

--On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" 
<john.elwell <at> siemens.com> wrote:

> There seem to be some differences of opinion concerning the use of
> P-Asserted-Identity (PAI) in a response. In particular, this is delaying
> the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a
> 200 OK to convey the connected party identity received from the QSIG
> network. The same situation is likely to be encountered when interworking
> with other legacy signalling systems.
>
> It is my opinion that PAI can be used in a 200 OK to assert the identity
> of the connect party. Moreover, it can be inserted by a gateway UAS and,
> unless subject to privacy, can be passed on even to untrusted entities
> including the UAC.
>
> My evidence for assuming this is as follows:
>
> 1. RFC 3325: In section 5, 2nd paragraph it states:
> "If the proxy receives a message (request or response) from a node that it
> trusts, it can use the information in the P-Asserted-Identity header
> field, if any, as if it had authenticated the user itself."
> There is nowhere that forbids the use of P-Asserted-ID in a response,
> although there are places in the RFC that mention procedures for a request
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Taylor | 4 Jan 2004 01:27

Re: Use of P-Asserted-Identity in a response

I would also support this usage.

David Oran wrote:

> These arguments are good ones.
> Even if they weren't good I'd still be in favor of what John proposes, 
> because it's eminently reasonable and provides desperately needed 
> functionality for which we currently have no alternative machinery.
> 
> Dave.
> 
> --On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" 
> <john.elwell <at> siemens.com> wrote:
> 
>> There seem to be some differences of opinion concerning the use of
>> P-Asserted-Identity (PAI) in a response. In particular, this is delaying
>> the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a
>> 200 OK to convey the connected party identity received from the QSIG
>> network. The same situation is likely to be encountered when interworking
>> with other legacy signalling systems.
>>
>> It is my opinion that PAI can be used in a 200 OK to assert the identity
>> of the connect party. Moreover, it can be inserted by a gateway UAS and,
>> unless subject to privacy, can be passed on even to untrusted entities
>> including the UAC.
>>
>> My evidence for assuming this is as follows:
>>
>> 1. RFC 3325: In section 5, 2nd paragraph it states:
>> "If the proxy receives a message (request or response) from a node
(Continue reading)

Permalink | Reply | 0 comments |
headers
Drage, Keith (Keith | 4 Jan 2004 01:57
Picon
Favicon

RE: Use of P-Asserted-Identity in a response

RFC 3325 section 9.1 and section 9.2 both extend table 2 of RFC 3261 with the new header.

Both entires leave the "where" column empty.

The key to RFC 3261 table 2 states:

      An empty entry in the "where" column indicates that the header
           field may be present in all requests and responses.

I would therefore conclude from the existing specification that both headers may appear in any response to
BYE, INV, OPT, SUB, NOT, REF, i.e. those methods that either create a dialog, or are used outside a dialog.

As MESSAGE appeared after RFC 3325 I would also assume that it is allowed in the MESSAGE method, in both
requests and all responses.

Note that these tables do not restrict it to 18x and 2xx responses, although for ISDN mapping purposes those
responses are the useful ones. It is perfectly valid in 3xx, 4xx and 5xx responses.

Any assertion of identity in responses (and its value) is of course dependent on the specification of
privacy by the UAS and on the requirements of the first proxy in the trust domain.

This usage corresponds to what has been specified in 3GPP TS 24.229 and I believe in ITU-T Q.1912.5.

regards

Keith 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell <at> siemens.com]
> Sent: 02 January 2004 16:11
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rene Bartsch | 4 Jan 2004 17:43
Picon

Emergency Calls with SIP?

Hi,

currently I'm faced with the problem of emergency calls.

As you need to gather the location of the caller to connect to the nearest 
emergency center when 911, 110, 112, ... is dialed, SIP needs some way for 
determining location.

My idea is to store a location-tag (e.g. address or GPS-data) in the 
SIP-phone, which is transmitted to the SIP-provider in case an emergency 
number is dialed.
That way the SIP-provider can determine the appropriate emergency center by 
country and zip/area code transmitting three addresses to the emergency 
center:

location, SIP-account holder and IP.

With location you can send help directly (e.g. ambulance). In case of wrong 
location or misuse you can investigate the caller by account-holder address 
and IP.

Are there any RFCs or Drafts for a emergency-call use-case with SIP?

Rene Bartsch

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tom Taylor | 4 Jan 2004 22:22

Re: Emergency Calls with SIP?

Henning Schulrinne wrote a number of relevant drafts.  The topic of 
connection from a SIP phone to a legacy emergency call centre was 
explored in draft-taylor-sipping-emerg-scen-01.txt, which also gives the 
references to Henning's drafts.

Rene Bartsch wrote:

> Hi,
> 
> currently I'm faced with the problem of emergency calls.
> 
> As you need to gather the location of the caller to connect to the nearest 
> emergency center when 911, 110, 112, ... is dialed, SIP needs some way for 
> determining location.
> 
> My idea is to store a location-tag (e.g. address or GPS-data) in the 
> SIP-phone, which is transmitted to the SIP-provider in case an emergency 
> number is dialed.
> That way the SIP-provider can determine the appropriate emergency center by 
> country and zip/area code transmitting three addresses to the emergency 
> center:
> 
> location, SIP-account holder and IP.
> 
> With location you can send help directly (e.g. ambulance). In case of wrong 
> location or misuse you can investigate the caller by account-holder address 
> and IP.
> 
> Are there any RFCs or Drafts for a emergency-call use-case with SIP?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
nataraju.alilaghatta | 5 Jan 2004 09:08

RE: Subscribe dialog and target refresh request


Regards,
Nataraju A.B. 

-----Original Message-----
From: sip-admin <at> ietf.org [mailto:sip-admin <at> ietf.org] On Behalf Of Sanjay
Sinha
Sent: Saturday, January 03, 2004 12:28 AM
To: sip <at> ietf.org
Subject: [Sip] Subscribe dialog and target refresh request

Hi,

For a dialog initiated with SUBSCRIBE, can a subscription for a new 
event on that dialog also be a target refresh request?

[Natraj] No, it's not a Target refresh request. Target refresh could
only happen either through INVITE or UPDATE requests.. 

- Sanjay.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
(Continue reading)

Permalink | Reply | 0 comments |

Gmane