headers
Arjun Roychowdhury | 1 Dec 2007 01:50

Re: Combining alert-info with file-transfer-mech

A calls B, passes B a file URL to potentially use as an alert.
Currently, examples of Alert-info describe using an HTTP get to get that URL
and render it.

However, file-transfer-mech provides details in the SDP that use MSRP
instead of HTTP-GET to transfer the file. In addition file-transfer-mech
provides the capability of adding meta information, amongst other things.

So what I am looking for is this "Hey B, I am want to call you, but use this
ringtone, and grab it using MSRP not HTTP. To boot look inside my SDP to see
more meta-information that will help you download, including an MD5 checksum
to ensure you downloaded what I think I asked you to download"

regds
arjun

On Nov 30, 2007 5:53 PM, Paul Kyzivat <pkyzivat <at> cisco.com> wrote:

> Huh???
>
> I don't understand what you have in mind.
>
>        Paul
>
> Arjun Roychowdhury wrote:
> > Hi,
> > I am working on a scenario where Alert-info would be included in an
> INVITE
> > request. However, in the same request, I want to bind the 'download'
> > mechanism of the file pointed to in Alert-Info with the file transfer
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Kyzivat | 1 Dec 2007 20:18
Picon
Favicon

Re: Combining alert-info with file-transfer-mech

I don't see any way to do that. I think you would need either:
- a special URL type, that implies accessing file with MSRP
- use a CID URL to reference an attached body, of some special
   type that is like a content indirection but that specifies
   using MSRP.

Both require stuff currently undefined.

	Paul

Arjun Roychowdhury wrote:
> A calls B, passes B a file URL to potentially use as an alert.
> Currently, examples of Alert-info describe using an HTTP get to get that 
> URL and render it.
>  
> However, file-transfer-mech provides details in the SDP that use MSRP 
> instead of HTTP-GET to transfer the file. In addition file-transfer-mech 
> provides the capability of adding meta information, amongst other things.
>  
> So what I am looking for is this "Hey B, I am want to call you, but use 
> this ringtone, and grab it using MSRP not HTTP. To boot look inside my 
> SDP to see more meta-information that will help you download, including 
> an MD5 checksum to ensure you downloaded what I think I asked you to 
> download"
>  
> regds
> arjun
> 
> On Nov 30, 2007 5:53 PM, Paul Kyzivat <pkyzivat <at> cisco.com 
> <mailto:pkyzivat <at> cisco.com>> wrote:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arjun Roychowdhury | 2 Dec 2007 21:13

Re: Combining alert-info with file-transfer-mech

like this?
regds
arjun

INVITE userB <at> foo.com SIP/2.0
From:userA <at> foo.com
Call-ID:
Alert-Info:cid:myringtone <at> foo.com
Content-Type:multipart/mixed; boundary=bound12
--bound12
Content-Type: application/sdp
... The SDP for the call goes here
--bound12
Content-ID:myringtone <at> foo.com
Content-Type:application/sdp
Content-Length:
...
...
m=message 9999 TCP/MSRP *
.
.
.
a=path:msrp://myurltoringtone:9999/342sf;tcp

On Dec 1, 2007 2:18 PM, Paul Kyzivat <pkyzivat <at> cisco.com> wrote:

> I don't see any way to do that. I think you would need either:
> - a special URL type, that implies accessing file with MSRP
> - use a CID URL to reference an attached body, of some special
>   type that is like a content indirection but that specifies
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Kyzivat | 3 Dec 2007 02:54
Picon
Favicon

Re: Combining alert-info with file-transfer-mech

Well, that is very imaginative. But at best it is a use case for a new 
standard. There is currently no reason to believe that any UA that 
received such and INVITE would have the slightest idea what to do with it.

I guess you could propose some new work in this area. But you might want 
to start by explaining why anyone would want to do this.

	Paul

Arjun Roychowdhury wrote:
> like this?
> regds
> arjun
>  
> INVITE userB <at> foo.com <mailto:userB <at> foo.com> SIP/2.0
> From:userA <at> foo.com <mailto:From:userA <at> foo.com>
> Call-ID:
> Alert-Info:cid:myringtone <at> foo.com <mailto:Alert-Info:cid:myringtone <at> foo.com>
> Content-Type:multipart/mixed; boundary=bound12
> --bound12
> Content-Type: application/sdp
> ... The SDP for the call goes here
> --bound12
> Content-ID:myringtone <at> foo.com <mailto:Content-ID:myringtone <at> foo.com>
> Content-Type:application/sdp
> Content-Length:
> ...
> ...
> m=message 9999 TCP/MSRP *
> .
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arjun Roychowdhury | 3 Dec 2007 03:36

Re: Combining alert-info with file-transfer-mech

Yes, I understand this is a new proposal.
The use-case is straightforward - for situations where miguel's MSRP
extensions are useful, there should be a way to associate any header in SIP
which may pass a 'resource' that benefits from miguel's extensions and MSRP.
The first usecase, of course, is ringtone download.

As far as I can tell, everything in the example below is compliant to
different standards:

the usage of CID  & pointer to a multipart body is compliant to RFC 2111
the usage of file-transfer-mech and MSRP are compliant to their respective
drafts.

The main thing of-course, is no UA will understand this, but as long as it
is not breaking the intentions of these drafts/RFCs, I should think it makes
a case for a new draft :-)

regds
arjun

On Dec 2, 2007 8:54 PM, Paul Kyzivat <pkyzivat <at> cisco.com> wrote:

> Well, that is very imaginative. But at best it is a use case for a new
> standard. There is currently no reason to believe that any UA that
> received such and INVITE would have the slightest idea what to do with it.
>
> I guess you could propose some new work in this area. But you might want
> to start by explaining why anyone would want to do this.
>
>        Paul
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sanjay Sinha (sanjsinh | 3 Dec 2007 04:43
Picon
Favicon

Re: MSRP with Failure-Report header No/Partial

There will always be a response to SEND request, irrespective of value
of Failure-Report header.

Sanjay

________________________________

	From: Vikas Jayaprakash [mailto:vikas.jayaprakash <at> gmail.com] 
	Sent: Friday, November 30, 2007 12:53 AM
	To: Sanjay Sinha (sanjsinh)
	Cc: sip-implementors <at> lists.cs.columbia.edu
	Subject: Re: [Sip-implementors] MSRP with Failure-Report header
No/Partial
	
	
	Hi,
	
	Please correct me if my understanding is wrong.
	
	I will put it this way. What about the transaction response from
Relay back to Orig UE when:
	
	1. When Relay receives an error-free MSRP SEND request with
Failure-Report =No. 
	Did you mean Final response is sent back to Orig UE?
	
	2. When Relay receives an error-free MSRP SEND request with
Failure-Report =Partial.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Langstaff | 3 Dec 2007 10:49

Re: SDP negotiation: PCMU/8000 Vs PCMU/16000

> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu 
> [mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On 
> Behalf Of Richard Wu
> Sent: 29 November 2007 06:03
> To: sip-implementors <at> lists.cs.columbia.edu
> Subject: [Sip-implementors] SDP negotiation: PCMU/8000 Vs PCMU/16000
> 
> Hi All,
>    I have a quest ion about SDP negotiation of the same codec 
> with different sampling rate.
> Suppose A with the following SDP
> 
> m=audio 49232 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> 
> and B with:
> m=audio 23425 RTP/AVP 98
> a=rtpmap:98 PCMU/16000
> 
> 
> Does these two SDPs match (having intersection)? How's about 
> if one is mono and other is stereo?

RFC 4566 says of the rtpmap line:

      a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
         parameters>]

[snip]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Wu | 3 Dec 2007 11:02

Re: SDP negotiation: PCMU/8000 Vs PCMU/16000

Hi Steve,

   Maybe my last question has a little of bit confusion. My question is: 
if offer is mono using PCMU/8000 and the answer is stereo (PCMU/8000/2), 
do these two SDPs match (having intersection)?

Regards,
Richard

Steve Langstaff wrote:
>> -----Original Message-----
>> From: sip-implementors-bounces <at> lists.cs.columbia.edu 
>> [mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On 
>> Behalf Of Richard Wu
>> Sent: 29 November 2007 06:03
>> To: sip-implementors <at> lists.cs.columbia.edu
>> Subject: [Sip-implementors] SDP negotiation: PCMU/8000 Vs PCMU/16000
>>
>> Hi All,
>>    I have a quest ion about SDP negotiation of the same codec 
>> with different sampling rate.
>> Suppose A with the following SDP
>>
>> m=audio 49232 RTP/AVP 0
>> a=rtpmap:0 PCMU/8000
>>
>> and B with:
>> m=audio 23425 RTP/AVP 98
>> a=rtpmap:98 PCMU/16000
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Samira Salam | 3 Dec 2007 16:23
Picon
Favicon

An efficient SIP Programming Interface

Hi ,
  As a part of my MS project I proposed a 3-party authentication protocol which can be used in SIP too. for SIP.
The proxy server utilizes this protocol to  authenticate the UC's Invite,using the Registrar server.
Now, I have to estimate the totoal overhead of the scheme on a normal  SIP call.  I searched dozens of  SIP,
UMTS, GSM related papers to find a simulator or emulator which could be used to to achive the goal but I
couldn't get any solutions as I needed to consider eexecution of the RSA,AES and SHA on the agent's
processor. Could you please tell me what is a rapid(due to my time constraints) solution for me?any
simulation technique?any piece of software or programmining interface? By the way I am a little familiar
with opnet as I did a tiny project with it. Doest it help me?

  Thanks in advance.
  Samira.

       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
Permalink | Reply | 0 comments |
headers
Sanjay Sinha (sanjsinh | 3 Dec 2007 18:14
Picon
Favicon

Re: SUBSCRIBE and REFER within INVITE dialog

Pl. look at RFC 5057

>-----Original Message-----
>From: sip-implementors-bounces <at> lists.cs.columbia.edu 
>[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On 
>Behalf Of johnny kao
>Sent: Tuesday, November 20, 2007 8:07 PM
>To: sip-implementors <at> lists.cs.columbia.edu
>Subject: Re: [Sip-implementors] SUBSCRIBE and REFER within 
>INVITE dialog
>
>Hi,
>
>I'm curious about this problem, too. Hope for more discussion 
>on this topic.
>
>In RFC 3265, a more complicate condition, more than one 
>subscriptions associated to a  dialog is possible. If a dialog 
>constructed by an INVITE receives a BYE to terminate the 
>dialog, does all subscriptions terminate automatically because 
>of the BYE?
>
>Or, this is only legal in RFC, it couldn't happen?
>
>BR,
>Johnny
>
>2007/3/8, Nina Garaca <nina.garaca <at> zesium.com>:
>> >
>> > Hi,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane