2.8.17 Session Initiation Protocol (sip)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.softarmor.com/sipwg/ -- Additional SIP Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Interim Joint Meeting - Session Initiation Protocol (sip)/Session Initiation Proposal Investigation (sipping)

Last Modified: 2004-06-14

Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Technical Advisor(s):
Dan Romascanu <dromasca@avaya.com>
Mailing Lists:
General Discussion: sip@ietf.org
To Subscribe: sip-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/sip/index.html
Description of Working Group:
Note: There is another SIP email list for general information and implementations:

Discussion of existing sip: sip-implementors@cs.columbia.edu To Subscribe: sip-implementors-request@cs.columbia.edu In Body: subscribe Archive: http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors =======================================================================

The Session Initiation Protocol (SIP) working group is chartered to continue the development of SIP, currently specified as proposed standard RFC 2543. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main work of the group involves bringing SIP from proposed to draft standard, in addition to specifying and developing proposed extensions that arise out of strong requirements. The SIP working group will concentrate on the specification of SIP and its extensions, and will not explore the use of SIP for specific environments or applications. It will, however respond to general-purpose requirements for changes to SIP provided by other working groups, including the SIPPING working group, when those requirements are within the scope and charter of SIP.

Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Extensions and new features must be generally applicable, and not applicable only to a specific set of session types.

3. Simplicity is key.

4. Reuse of existing IP protocols and architectures, and integrating with other IP applications, is crucial.

SIP was first developed within the Multiparty Multimedia Session Control (MMUSIC) working group, and the SIP working group will continue to maintain active communications with MMUSIC. This is particularly important since the main MIME type carried in SIP messages, the Session Description Protocol (SDP), specified in RFC 2327, is developed by MMUSIC and because MMUSIC is developing a successor to SDP which SIP will also use.

The group will work very closely with the (proposed) SIPPING WG, which is expected to analyze the requirements for application of SIP to several different tasks, and with the SIMPLE WG, which is using SIP for messaging and presence.

The group will also maintain open dialogues with the IP telephony (IPTEL) WG, whose Call Processing Language (CPL) relates to many features of SIP; will continue to consider the requirements and specifications previously established by the PSTN and Internet Internetworking (PINT) working group;: and will consider input from the Distributed Call Signaling (DCS) Group of the PacketCable Consortium for distributed telephony services, and from 3GPP, 3GPP2, and MWIF for third-generation wireless network requirements.

The specific deliverables of the group are:

1. bis: A draft standard version of SIP.

2. callcontrol: Completion of the SIP call control specifications, which enables multiparty services, such as transfer and bridged sessions.

3. callerpref: Completion of the SIP caller preferences extensions, which enables intelligent call routing services.

4. mib: Define a MIB for SIP nodes.

5. precon: Completion of the SIP extensions needed to assure satisfaction of external preconditions such as QoS establishment.

6. state: Completion of the SIP extensions needed to manage state within signaling, aka SIP "cookies".

7. priv: Completion of SIP extensions for security and privacy.

8. security: Assuring generally adequate security and privacy mechanisms within SIP.

9. provrel: Completion of the SIP extensions needed for reliability of provisional messages.

10. servfeat: Completion of the SIP extensions needed for negotiation ofserver features.

11. sesstimer: Completion of the SIP Session Timer extension.

12. events: Completion of the SIP Events extensions (Subscribe/Notify).

13. security: Requirements for Privacy and Security.

14. compression: SIP mechanisms for negotiating and guidelines for using signaling compression as defined in ROHC.

15. content indirection: a Proposed Standard Mechanism to reference SIP content indirectly (by reference, for example using an external URI).

Other deliverables may be agreed upon as extensions are proposed. New deliverables must be approved by the Transport Area Directors before inclusion on the agenda.

NOTE: milestones within the same month are shown in order of planned completion.

Goals and Milestones:
Done  Server Features Negotiation submitted to IESG
Done  Complete IESG requested fixes to provrel and servfeat
Done  Revised proposed standard version of SIP (2543bis) submitted to IESG
Done  SIP Events specification to IESG
Done  The UPDATE Method submitted for Proposed Standard
Done  SIP extensions for media authorization (call-auth) submitted as Informational
Done  Preconditions extensions (manyfolks) spec to IESG
Done  SIP Privacy specification to IESG
Done  SIP Privacy and Security Requirements to IESG
Done  The MESSAGE Method submitted for Proposed Standard
Done  The Replaces Header submitted for Proposed Standard
Done  Refer spec to IESG
Done  SIP NAT extension submitted to IESG
Done  SIP over SCTP specification and applicability statement
Done  Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard
Done  The SIP Referred-By Header submitted to IESG for Proposed Standard
Done  Session Timer spec, revised to IESG
Done  Caller preferences specification submitted to IESG
Done  Submit SIP Identity documents to IESG for Proposed Standard
Done  The SIP Join Header submitted to IESG for Proposed Standard
Done  Replaces header to IESG (PS)
Done  Upgrade S/MIME requirement for AES in 3261 to IESG (PS)
Mar 04  Application Interaction to IESG (BCP)
Mar 04  Resource Priority signaling mechanism to IESG (PS)
Done  Presence Publication to IESG (PS)
Apr 04  Guidelines for Authors of SIP extensions submitted as Informational
Apr 04  Connection reuse mechanism to IESG (PS)
Apr 04  Enhancements for Authenticated Identity Management to IESG (BCP)
May 04  Mechanism for obtaining globally routable unique URIs to IESG (PS)
Jun 04  MIB spec to IESG
Sep 04  Review WG status (consider closing) and/or submit a future milestones plan to IESG
Sep 04  Request History mechanism to IESG (PS)
  • - draft-ietf-sip-session-timer-14.txt
  • - draft-ietf-sip-callerprefs-10.txt
  • - draft-ietf-sip-mib-08.txt
  • - draft-ietf-sip-guidelines-08.txt
  • - draft-ietf-sip-sctp-04.txt
  • - draft-ietf-sip-replaces-05.txt
  • - draft-ietf-sip-referredby-05.txt
  • - draft-ietf-sip-compression-02.txt
  • - draft-ietf-sip-content-indirect-mech-04.txt
  • - draft-ietf-sip-join-03.txt
  • - draft-ietf-sip-identity-02.txt
  • - draft-ietf-sip-authid-body-03.txt
  • - draft-ietf-sip-history-info-03.txt
  • - draft-ietf-sip-resource-priority-03.txt
  • - draft-ietf-sip-callee-caps-03.txt
  • - draft-ietf-sip-connect-reuse-02.txt
  • - draft-ietf-sip-uri-parameter-reg-02.txt
  • - draft-ietf-sip-parameter-registry-02.txt
  • - draft-ietf-sip-publish-04.txt
  • - draft-ietf-sip-rfc3312-update-01.txt
  • - draft-ietf-sip-gruu-02.txt
  • - draft-ietf-sip-anat-usage-00.txt
  • Request For Comments:
    RFC2976 PS The SIP INFO Method
    RFC3204 PS MIME media types for ISUP and QSIG Objects
    RFC3261 PS SIP: Session Initiation Protocol
    RFC3262 PS Reliability of Provisional Responses in SIP
    RFC3263 PS SIP: Locating SIP Servers
    RFC3265 PS SIP-Specific Event Notification
    RFC3361 PS DHCP Option for SIP Servers
    RFC3310 I Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)
    RFC3311 PS The Session Initiation Protocol UPDATE Method
    RFC3312 PS Integration of Resource Management and SIP
    RFC3420 PS Internet Media Type message/sipfrag
    RFC3323 PS A Privacy Mechanism for the Session Initiation Protocol (SIP)
    RFC3325 I Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
    RFC3428 PS Session Initiation Protocol Extension for Instant Messaging
    RFC3326 PS The Reason Header Field for the Session Initiation Protocol (SIP)
    RFC3327 PS Session Initiation Protocol Extension for Registering Non-Adjacent Contacts
    RFC3329 PS Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions
    RFC3313 I Private Session Initiation Protocol (SIP)Extensions for Media Authorization
    RFC3515 PS The Session Initiation Protocol (SIP) Refer Method
    RFC3319 PS Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers
    RFC3581 PS An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
    RFC3608StandardSession Initiation Protocol Extension Header Field for Service Route Discovery During Registration
    RFC3853StandardS/MIME AES Requirement for SIP

    Current Meeting Report

    SIP Minutes, IETF 60

    Draft Minutes, SIP, IETF 60

    Edited by Dean Willis  -- WORK IN PROGRESS!!!!!

    Session 1, Wednesday, August 4, 0900-1130

    Agenda modified to substitute discussion of body part modification instead of resource priority..

    Topic: Status of Working Group

    Discussion led by chairs. Slides presented.

    Discussion of Non-Invite Transaction Drafts: <>Consensus reported that two Non-Invite drafts are ready for WGLC: draft-sparks-sip-nit-problems-01.txt and draft-sparks-sip-nit-actions-01.txt. The chairs are to arrange for WGLC.

    "SIPPING 16": Proposed that the WG should prepare a document denying that there is some set number of possible SIP features. Discussion centered on whether or not this should be an RFC. Resolved: We will sart with a draft and consider it as usual.

    Topic: Content Indirection

    Discussion led by Dean Willis acting as Editor. Slides presented.

    Issue: Editor. Volunteers were requested to replace Seann Olson, who is not able to contribute at this time. Eric Burger volunteered.

    Issue: Do we need content expiration? Do we have to update RFC 2017 to add it?  Rough consensus seem to be to retain this function, as it was present for WGLC and IETF LC. The document editor is to discuss the addition on the ietf-types mailing list and determine whether a change to RFC 2017 is needed.

    Issue: Hash format. Consensus that the hash parameter should be named, as per "hash-sha1". The hash value shall be wrapped in double quotes. The editor is tasked with reviewing the hash parameter on the ietf-types list.

    Issue: Partial rejection of content. Noted that some RFC (3359?) allows rejecting non-critical content. The editor is directed to clarify this in the text, potentially discarding confusing section 5.10 text .

    Topic: Body Part Modification by Proxies

    Discussion led by Rohan Mahy as Author. Slides presented.

    Background of problem presented along with use cases and a variety of topologies including triangle, trapezoid, and local as well as foreign piggybacking.

    Discussion was heated and active. This is clearly a controversial topic.

    Notable points from the discussion:
    1. This is related to the policy discussion.
    2. Modification of bodies has a significant impact on the security model, and seems to require that S/MIME be applied on a per-part basis rather than per-message basis.
    3. Having individual body parts signed by different entities is problemactic.
    4. Any solution is going to have to address a large number of uses cases.
    Discussion will continue, with no consensus recorded at this time.

    Topic: Connection Reuse

    Discussion led by Rohan Mahy as Author. Slides presented.

    The main issue seems to be around identifying a specific connection in a manner suitable for use as a reference. The URI doesn't provide adequate context, except in the case of a GRUU which is instantiated by the element using the reference.

    Discussion will continue, with no consensus recorded at this time.

    Topic: Authenticated Identity

    Discussion led by Jon Peterson as Author. Slides presented.

    Issue: Retargeting vs. Redirection. The proposed approach effectively denigrates retargeting in cases where identify functions are performed by the retargeting element. Noted that this isn't all bad -- redirection offers a majority of the capabilities needed, without the problems introduced by retargeting including response identity, multiple forking response resolution, and so on. However, it does NOT provide some of the benefits, including proxy control, proxy-facilitated NAT traversal (especially with connection-reuse), and privacy control.

    Does non-local retargeting go away so we can get identity? Don’t want security property downgrading – more choices allow more downgrading. If identity is critical, we’ve got to go there – not with a flag day, but we’ve got to go there.

    Specific aspects discussed include:
    1. Does this contradict caller preferences? Jonathan thinks “no”.
    2. This doesn’t mess up request-history (after thinking about it a while).
    3. Do all the applications work? Extra RTTs are OK, although they'll chafe the wireless community.
    4. Need to make requirements so we can make sure we meet them.
    5. Cost-benefit from a speed perspective is subtle (and probably small as well). Almost all forwards are local forwards, and almost all phone calls have local forwards today.
    6. “The main thing is to make sure this actually works in a practical sense, and I’m not there yet.”
    7. RFC 3261 limits recursion – but was this text ever coherent? Would we clarify this text?
    8. This probably will slow down call setup in wireless domains, but it’s not unreasonable for retargeted calls to be slower. SIGCOMP helps here, too.
    9. RFC 3261 is pretty clear on who can muck with Request-URI – this should work.
    It was observed that few participants in the room displayed confidence in their understanding of the problem or the proposal, and that further study would be a Good Thing.

    Topic:  GRUU

    Discussion led by Jonathan Rosenberg asAuthor. Slides presented.

    Issue:  URN Equality. Consensus indicated to use lexical equality where a specific quality function for a URN is not specified and known to the element.

    Issue: Ramp-up problem. The current text requires that registrars refuse registrations resulting in a conflict, after which restarting devices that caused the conflict can remove the old registration before trying to re-register. This reduces the capacity during a restart by a factor of four over simply overwriting the old registration. Proposals include overriding the old registration, or keeping both contacts. Several alternatives and issues were discussed, with key comments including.
    1. Question: Does having two registrations for same instance violate a critical GRUU property?
    2. Worry: Keeping both might contribute to another avalanche restart problem, and is more complicated<>
    3. <>Preference: (Paul K). prefers overriding oldregistration.Comment  (Rosenberg) - Ok to have multiple routes/connections for an instance, so #1 above is "no".
    4. <>
    5. Question: (Rohan) Could we use a flag or special response code to tell the registering mobile than an existing instance has been overridden and that something odd must have happened?
    6. Worry:  Multiple contacts with the same instance id complicates the way proxies handle certain errors. Complicates a lot of  things.
    7. <>
    8. Comment:  (Sparks) - Sounds familiar with Etag and XCAP.
    No consensus observed on the ramp-up issue.

    Session Two, Thursday, August 5 1300-1500

    Topic: SIP MIB

    Discussion led by Rohan Mahy as Chair.

    Proposals to close 3 of the 4 known open issues were made on the list. One issue remains. Rohan propsoes that the MIB functions related to configuring SIP UAs be deleted, as we have a seperate UA configuration framework. Some elemenst would remain, but as read-only. The group indicated a consensus to proceed with this approach.

    New issue raised: We added an application index to all these tables. The problem is to define application name may end up in the same name repeated. Is this legal? The problem is that the same application is an instance of the same application. RFC 2788 seems to say one entry per application. The MIB spec is restricted in the name. A suffix to the application name may solve the issue, although this point is not agreed. Follow up on the list.

    Topic: The History of History and Voicemail, A Diatribe by Cullen Jennings

    Discussion led by Cullen Jennings as Amicus Curae, with slides presented.

    Two solutions for users with voice mail.
    1.    History: proxies retarget include information about where and why they retargeted.
    2.    Voicemail uri: proxies figure out what services they want voicemail to provide and tell the voicemail the voicemail to do that

    Slides: A long list of drafts that request this issue.

    Slides: reviewed the history of changes in voicemail-uri.

    Proposal: The possibility of using both: Cullen indicates that both seem to be needed and not mutually exclusive..

    Recommendation: chose something now: History, URI, Both. The recommendation is to use both, since the do different things and they
    work together.

    Rohan, as chair: We are already doing History. So the question is: we do History alone or we do History AND URI.

    Poll: Anyone implementing voicemail URI? No answers.

    Suggestion by Dean as Chair: to take voicemail URI as an individual submission heading to informational RFC, and proceed with History as planned in the working group. There seemed to be general consensus to proceed with thsi approach.

    Topic:  Request History

    Discussion led by Mary Barnes as Author. Slides presented.

    Mary goes through the changes from -02 (see slides)

    Issue: Section 4.1 has normative statements that appear to overlap with the normative ABNF. Resolved that the author will make the text explicative rathen than using requirements language therein.

    Broader review is now desirable. The author feels that the document is ready for WGLC, and there seems to be a consensus in the room  to proceed with last call.

    Mary presents an analysis of History-Info vs robust security:
    comparison with draft-ietf-sip-identity-02 and
    draft-ietf-mahy-sipping-add-body (see slides).

    Mary also presents an analysis of History-Info versus Privacy.

    Discussion ensued, with key lements being:
    1. Jon: People are much confortable with the request portion than with the response portion in the request identity draft. Suggest to split<>the request-identity in two drafts. Considering to work on two optionsfor request-history as well, since they are incompatible.<>Rohan: transition mechanism that the P-Asserted-Identity to thegeneral internet. 
    2. Jon: the request identity draft just says that a proxy cannot add a body.<>Keith: we need to solve the ientity stuff before the history, not the other way round.<>
    3. Rohan: is is sufficient to say in history-info that a proxy that retargets to a non-local then it should redirect. This will work. Other mechanisms may be specified later. If a proxy want to convey history-info securily, then you can redirect to TLS.
    Rohan is to send text to  Mary as per above.

    Topic: Connected Party -- who am I talking to?

    Discussion led by Cullen Jennings as Author. Slides presented.

    Problem description in the slides.  Possible solutions:
    1) update of state in the dialog;
    2) transfer to a new user.

    Noted that 1) has two

    1a) Update To or From, although is not compatible to 2543.
    1b) update with a new header, body, AIB, etc. Compatible with 2543, but a 2543 phone will not update its display.

    1. Jonathan: With respect to 1A, I hope people are not using To and From as the primary source of information for the user.
    2. Rohan: WRT solution 1a and 2543. A 2543 implementation will return 481. To and From are useless today.
    3. Andrew: don't depend on To and From headers, the UA will not use them.
    4. Jon: email contains From and To headers, and they are useful and intuitive. They can be forged, and that's why we need identity, and this is approach taken by identity, making them meaningful. it requires a lot of motivation to make the to/from header less meaningful.
    5. Jiri: In forwarding scenarios across different domains, there is not traces of the original sender.
    6. Keith: the problem is reusing a header for different usage. This is the problem why we end up with so many identities.
    7. Rohan: the semantics of from/to: To is a semantics of to which you address the dialog. Cullen suggests the semantics of to who you are communicating. The identity work addresses part of this correlation.
    8. Rohan: if we go with 1a and do not change the To header, someone has to change a bunch of stuff in Section 26 of 3261 to indicate how to do things now with  S/MIME. 
    9. Hisham: ok to change To/From, if you authenticate the user you don't authenticate the To/From. If I want to change my name, I can re-INVITE to change my From. 
    10. Cullen: sort of agree with Hisham. right now we don't have a mechanism to change the name. Solution 2 is about INVITE/Replaces, not about REFER.
    11. Jonathan: Think about the way many people visualize billing systems toay --  the billing system charges the user on INVITE and BYE. This is wrong. The billing system should take information about "what happens" during the call, and figure out that information when the call started/ stopped.
    12. Jonathan: don't understand the serious security issues (see slide, solution 2).
    13. Rohan: replaces has requirements for authorization of the replacement,and the way to do it is to look at the Referred-By header and correlated.
    14. Jonathan: a solution: GRUU + cryptographicly random grids
    Chair: I think I sense a developing consensus to look at the cryptographic technics of the GRUU and the dialog usage. Poll of the room about the possible solutions: Room prefers support for Replaces with GRUU and cryptographic randoms (solution 2). If that does not work, then try a new header (solution 1b).

    Topic: SIP State Update

    Discussion led by John Elwell as Author. Slides presented.

    Proposed: Treat the contents as clarifications to existing RFCs as bug fixes and add similar clarifications to authid-body and future drafts.

    Discussion: How does this related to the previous presentation. Do we need to put this on hold until we resolve the previous proposal?

    Chair proposal: Bring the list of bugs, one at a time, to the mailing list, so we can get attention focused on each and work through it.

    Topic: Making S/MIME Work With Certs

    Discussion led by Cullen Jennings as Author, with slides presented

    Issue: Fetching credentials: options are
    1. use notification
    2. use config framework
    3. use https

    Discussion follows.

    Several points were raised.
    1. The trick to make this deployable is to have one certificate per domain instead of a certificate per user.
    2. Tieing the lifetime of the certificate with the lifetime of the subscription solves a bunch of problems.
    3. Using HTTS to fetch a certificate could avoid a bunch of SIP messages.
    4. Jonathan: we can do this with zero call setup delay. buddylist provides a context to get certificate from my buddy. You can add a flag to a presence document "hasCert".
    5. Rohan: if I received a signed message from someone I don't have a certificate, for then HTTPS is better. From deployment perspective it's easier.
    6. Jonathan: this is easier to deploy with SIP. In which way the is the HTTP solution superior to the SIP solution?
    7. Maintaining a large number of subscriptions is server side state. The HTTP solution has no server side state. However, we already have the subscriptions for the buddy list. The subscription solution offers immediate notification of certificate revocation. However, the short subscription timer in certificates cannot be used, since it is expensive to generate certificates.
    8. Note that fetching the cert does not require TLS -- certs can be sent safely via plain HTTP.
    9. If HTTP is used, how does one compute the HTTP URI? SRV may already solve the problem.

    Further discussion deferred to list.

    Chair: we have a lot of dependencies on making S/MIME to work. There is strong consensus to make this work. Proposed to make this a WG item. Poll to the room indicates strong consensus to adopt this as WG item. Chairs are to work this out with the ADs.

    Topic: How offer/answer interacts with multipart/alternative in SIP

    Discussion led by Cullen Jennings, with slides presented.

    The problem of first trying a secure call and then the insecure, is that the secure call is prioritized (e.g, if the voicemail implements secure, S/MIME, SRTP, the voicemail will always answer).

    Proposed Solution: Content-ID in each multipart entity in the offer and a Content-Reference in the answer.

    AD: This is probably in the scope of the MIME WG.

    Issue: do we need a Require header. Proposal: yes

    Jonathan: weak feeling. If I do SRTP I need to encrypt the SDP. Better
    to start with the problem statement. The problem: I cannot use SRTP
    because it is a backward compatibility problem.
    Cullen: the solution to the bid down attack is the auth body and
    encrypt everything.
    Jonathan: there is two problem statements. Another problem is due to
    the consequences of sending secured multipart, the nonencrypting UA
    will reject.
    Dean: problem 1) how to find out if the other party can do SRTP or
    not. Solution: multipart. Alternative: send an offer encrypted, if
    rejected, send offer unencrypted, but what happens with forking.
    Jean Francois: the number of alternatives is big (encrypted voice,
    non-encrypted audio type of things). This may increase complexity and
    size of the multipart.
    Dave: Should it be possible to accept the session but reject the
    offer. Get a 200 OK, but sending something that "I want to establish
    the session, but there is something in the SDP that I don't
    Hisham: yes, you can reject everyhig in the answer
    Hisham: Can you offer both RTP and SRTP as options?
    Cullen: the problem is tha tif you do SRTP you need to encrypt.
    Aki: about the tag, inspire in the security agreement.
    Jonathan: may need to look at preconditions as a solution.
    Rohan: backwards compatibility is an issue, so preconditions does not

    Discussion is deferred to the list

    Using SAML for SIP -- Hannes Tschofenig

    Hannes goes through the slides. No comments.

    Chair To-Do List

    1. WGLC draft-sparks-nit-problems
    2. WGLC draft-sparks-nit-actions
    3. Work with MIB team to delete UA configuration.
    4. Rohan to send text to Mary clarifying that proxy retargeting to a non-local destination will redirect instead. When this is incorporated into request-history-mech, the draft will be WGLCed.
    5. Get certs work on-charter and add milestone.


    Content Indirection
    Request History Information
    To add bodies or not? ...that is the question
    Connection Reuse
    Using SAML for SIP
    History of Voicemail
    S/MIME and Certs
    Who Iím Talking To
    Offer/Answer & Multipart Alternative