Subject: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue

From: "Ramesh Ramamurthy" <[email-masked]>
Date: Wed, 2 Feb 2005 22:04:52 -0000

Hi,
I have sent a request for information to the author about the ClearMode
Draft and have not received any responce. Are we sure that this draft is
alive?

Thanks
Ramesh
Tom Taylor wrote:

>Hi.  My responses below marked with [PTT].
>
>FCG Wang JuLin wrote:
>  
>
>> 
>>
>>Hi,list,
>>
>>Is there any standard in  pri and sip mapping for the following three 
>>items:
>>
>>1)user to user infomation
>>    
>>
>
>[PTT]  To carry the information itself, the obvious method is to add a body of
>type application/octet-stream.  The issue comes in how to signal the service --
>especially, how to indicate what that body is for.
>  
>
>>2)bear capacity( 64K data),UDI.
>>    
>>
>
>[PTT] You can signal and use CLEARMODE
>(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt).  This
>has been approved by the IESG but is stuck in the RFC Editor's queue because it
>has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last
>Call.
>  
>
>>3) call transfer service indication mapping.
>>    
>>
>
>[PTT] Leaving aside 3xx redirection responses, you may want to look at the
>Request_History header field
>(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt).
>  
>
>>Thank you for your response  !
>>
>>Best Regards
>>Wang Julin(Jerry Wang)
>>Product Management
>>Alcatel Shanghai  Bell
>>Phone:+86-21-58541240-9531
>>Fax:+86-21-58342941
>>Mobile: 13817861240
>>E-mail:[email-masked]
>>
>>
>> 
>>
>> 
>>
>> 
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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
>>    
>>
>
>  
>
------
To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion

_______________________________________________
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

---

From: "Tom Taylor" <[email-masked]>
Date: Wed, 2 Feb 2005 22:04:52 -0000

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]
------
To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion

---

From: Takuya Sawada <[email-masked]>
Date: Thu, 3 Feb 2005 22:36:11 +0900

Hi,

> especially, how to indicate what that body is for.

I think one possible solution is to use ITU-T Q.1980.1.
MIME type will be the following;

  Content-Type: application/nss
  Content-Disposition: signal

The problem of this solution is that Q.1980.1 is not so popular, I think.

Am I correct?

Regards,
Takuya

> > E-mail:[email-masked]

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Thu, 03 Feb 2005 15:25:13 -0800

Q.1980.1 is text-encoded international ISUP.  In other words, it is an alternative 
to RFC 3204 binary ISUP encapsulation.  Since the question was about PRI rather 
thyan ISUP, neither Q.1980.1 nor RFC 3204 is a direct answer.

> The problem of this solution is that Q.1980.1 is not so popular, I think.
[snip]

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 4 Feb 2005 09:28:19 +0900

Hi,

In my understanding, the main difference between Q.1980.1 and RFC 3204,
other than format, is that the former allows partial message contents
and the latter only allows the whole complete message.

PRI gateway can not know how to construct the whole ISUP message which
is required to use RFC 3204. It can only know end-to-end information
like UUI or HLC/LLC, which is conveyed in ATP parameter in ISUP.
Then I think it may be useful for PRI gateway to set UUI infomation
in Q.1980.1 message body to carry it to the peer or the ISUP gateway,
theoretically.

* Should we move this discussion to sipping, if it continues? 
  or stop it now (as it is not an IETF work)?

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Takuya Sawada" <[email-masked]>
Date: Fri, 4 Feb 2005 00:32:47 -0000

Hi,

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)