·¢²©ÎÄ
¶«ºþÖ®±õ

linqo.blog.chinaunix.net

µ­²´ÒÔÃ÷Ö¾ Äþ¾²¶øÖÂÔ¶   
¸öÈË×ÊÁÏ
  • ²©¿Í·ÃÎÊ£º282181
  • ²©ÎÄÊýÁ¿£º99
  • ²©¿Í»ý·Ö£º7050
  • ²©¿ÍµÈ¼¶£ºÉÙ½«
  • ×¢²áʱ¼ä£º2006-04-21 11:32:30
¶©ÔÄÎҵIJ©¿Í
  • ¶©ÔÄ
  • ¶©Ôĵ½Ïʹû
  • ¶©Ôĵ½×¥Ïº
  • ¶©Ôĵ½Google
×ÖÌå´óС£º´ó ÖРС²©ÎÄ

    Address-of-Record: ¼Ç¼µØÖ·¡£Ò»¸öaddress-of-record(AOR)ÊÇÒ»¸öSIP»òÕßSIPS URIËüÖ¸ÏòÁËÒ»¸ö¾ßÓж¨Î»·þÎñµÄÖ÷»ú£¬Õâ¸öÖ÷»ú¿ÉÒÔ°ÑURIÓ³Éä³ÉΪÓû§ÕæÕýÎïÀíλÖõÄURI¡£Í¨³£Çé¿öÏ£¬¶¨Î»·þÎñÆ÷ÊÇͨ¹ýµÇ¼Ç·þÎñÀ´½¨Á¢µÄ¡£Ò»¸ö AOR¾­³£±»ÈÏΪÊÇÒ»¸öÓû§µÄ¡±¹«¹²µØÖ·¡±

    Back-to-Back UserAgent:±³¶Ô±³µÄÓû§´úÀí£¨B2BUA£©ÊÇÒ»¸öÂß¼­ÊµÌ壬Ëü¾ÍÏñÓû§´úÀí·þÎñÆ÷£¨UAS£©Ò»Ñù½ÓÊպʹ¦ÀíÇëÇó¡£ÎªÁ˾ö¶¨¸ÃÈçºÎÓ¦´ðÒ»¸öÇëÇó£¬ B2BUA¾ÍÏñUACÒ»Ñù¹¤×÷£¬²¢ÇÒ·¢³öÇëÇó¡£µ«ÊÇËü²»Ïñ´úÀí·þÎñÆ÷£¨proxy£©£¬Ëüά³Ö¶Ô»°×´Ì¬£¬²¢ÇÒ²ÎÓëÒѾ­½¨Á¢µÄ¶Ô»°ÖеÄÿһ¸öÇëÇó¡£ÓÉÓÚËüÊÇÖ± ½ÓµÄUACºÍUASµÄ´®Á¬£¬ËùÒÔ£¬²»ÐèÒª¶ÔËûÓжîÍâµÄ¶¨Òå¡£

    Call£ººô½Ð£¬Ò»¸öºô½ÐÊÇÒ»¸ö·ÇÕýʽµÄÊõÓËüÊÇÖ¸Ôڶ˵ãÖ®¼äÒ»¸öһЩͨѶÐÐΪ£¬Í¨³£ÓÃÓÚ½¨Á¢¶àýÌå¶Ô»°¡£
    Call Leg: ¶Ô»°µÄ±ðÃû£»ÔÚ±¾¹æ·¶ÖÐûÓÐʹÓá£

    Call Stateful: Èç¹ûÒ»¸ö´úÀí·þÎñÆ÷£¨proxy£©±£´æÒ»¸ö¶Ô»°µÄ״̬£¨´Ó×ʼµÄINVITEµ½¶Ô»°ÖÕ½áµÄBYE£©£¬ÄÇôÕâ¸ö´úÀí·þÎñÆ÷¾ÍÊÇÇëÇóÓÐ״̬µÄ¡£Ò»¸öÇëÇóÓÐ×´ ̬£¨call stateful£©µÄ´úÀí·þÎñÆ÷Ò²Ò»¶¨ÊÇÊÂÎñÓÐ״̬µÄ£¬µ«ÊÇÊÂÎñÓÐ״̬µÄ²»Ò»¶¨ÊÇÇëÇóÓÐ״̬µÄ¡£

    Client£º¿Í»§¶Ë¡£Ò»¸ö¿Í»§¶ËÊÇÒ»¸öÈÎÒâµÄÍøÂçÔªËØ£¬Ëü·¢³öSIPÇëÇóºÍ½ÓÊÕSIPÓ¦´ð¡£¿Í»§¶Ë¿ÉÄÜ»áÒ²¿ÉÄܲ»»áºÍÈ˽»»¥¡£Óû§´úÀí¿Í»§¶Ë£¨UAC£©ºÍ´úÀí·þÎñÆ÷¶¼Êǿͻ§¶Ë¡£

    Conference: Ò»¸ö°üº¬¶à¸ö²ÎÓë·½µÄ¶àýÌå»á»°£¨¼ûºó£©¡£

    Core£ººËÐÄ¡£ºËÐ͍ÒåÁËSIPʵÌåµÄÌØ¶¨Àà±ð¡£±ÈÈ綨ÒåÁËÒ»¸öÓÐ״̬ºÍÎÞ״̬µÄ´úÀí·þÎñÆ÷£¬Ò»¸öÓû§´úÀí»òÕß×¢²á·þÎñÆ÷£¨registrar£©¡£ËùÓеĺËÐÄ£¬³ýÁËÎÞ״̬´úÀí·þÎñÆ÷£¬¶¼ÊÇÊÂÎñÓû§¡£

    Dialog:¶Ô»°£¬Ò»¸ö¶Ô»°ÊdzÖÐøÒ»¶Îʱ¼äµÄÁ½¸öUAÖ®¼äµÄ¶Ëµ½¶ËµÄSIP¹ØÏµ¡£Ò»¸ö¶Ô»°ÓÉSIPÏûÏ¢½¨Á¢£¬¾ÍÏñÓÃ2xxÏìÓ¦INVITEÇëÇó¡£ ÎÒÃÇÓÃCall identifier£¬local tag£¨±¾µØtag£©£¬remote tag£¨¶Ô·½tag£©À´±êÖ¾Ò»¸ö¶Ô»°£¬Ò»¸ö¶Ô»°ÔÚRFC 2543Öб»Õýʽ½Ð×öCALL LEG.

    Downstream: ËüÊÇÊÂÎñÖеÄÏûÏ¢´«µÝ·½Ïò¡£ËüÌØÖ¸´ÓUACµ½UASµÄÇëÇóÁ÷µÄ·½Ïò£¬

    Final Response£ºÖÕ½áÏìÓ¦¡£Ò»¸öÏìÓ¦ÖÕ¶ËSIPÊÂÎñµÄÓ¦´ð£¬ºÍÊÂÎñÖмäµÄÁÙʱÏìÓ¦Ïà·´¡£ËùÓеÄ2xx£¬3xx£¬4xx£¬5xx£¬6xxÏìÓ¦¶¼ÊÇÖÕ½áÏìÓ¦¡£

    Header£ºÍ·¡£Í·ÓòÊÇÔÚSIPÏûϢͷ²¿ÓÃÀ´ÃèÊöÕâ¸öSIPÏûÏ¢ÐÅÏ¢µÄ²¿·Ö¡£ËüÓÉÒ»¶ÑÍ·Óò×Ö¶Î×é³É¡£

    Header Field:Í·Óò×ֶΡ£Í·Óò×Ö¶ÎÊÇÔÚSIPÏûϢͷÓòµÄ×ֶΡ£Ò»¸öÍ·Óò×ֶοÉÒÔÓɶà¸öÍ·Óò×Ö¶ÎÐÐ×é³É¡£Ò»¸öÍ·Óò×Ö¶ÎÓÉÒ»¸öÍ·ÓòÃûºÍ£¨Áã¸ö»ò¶à¸ö£©Í·ÓòÖµ×é³É¡£¶à¸öÍ·ÓòÖµÓá¯,¡¯·Ö¸î¡£Ä³Ð©Í·Óò×Ö¶ÎÖ»ÄÜÓе¥¸öÖµ£¬±ÈÈç½á¹ûÓò£¨result£©¾ÍÖ»ÄÜÓÐÒ»¸öÖµ¡£

    Header Field Value:Í·ÓòÖµ¡£Ò»¸öÍ·ÓòÖµÊÇÒ»¸öµ¥¸öµÄÖµ£¬Ò»¸öÍ·Óò×ֶοÉÒÔÓÐ0¸ö»òÕß¶à¸öÍ·ÓòÖµ¡£

    Home Domain£ºËÞÖ÷»ú¡£Ò»¸öÌṩSIP·þÎñµÄÖ÷»ú¡£Ò»°ãÖ¸µÄÊÇÔڵǼǷþÎñÖÐÖ¸Ã÷µÄ¼Ç¼µØÖ·ÖеÄURIµÄÖ÷»ú¡£

    Informational Response:ÌáʾӦ´ð¡£ºÍÁÙʱӦ´ðÒ»Ñù¡£
    Initiator, Calling Party, Caller: ÓÃINVITE³õʼһ¸ö»á»°£¨ºÍ¶Ô»°£©µÄÄÇ·½¡£Ò»¸öcaller´Ó·¢³öINVITEÇëÇó½¨Á¢¶Ô»°¿ªÊ¼£¬µ½¶Ô»°ÖÕÖ¹¶¼Ò»Ö±ÊÇÕâ¸ö½ÇÉ«¡£

    Invitation: Ò»¸öINVITEÇëÇó¡£

    Invitee,Invited User,Called Party, Callee:±»½Ð·½¡£ÊÕµ½INVITEÇëÇó²¢ÇÒ½¨Á¢»á»°µÄÄÇ·½¡£Ò»¸ö±»½Ð·½´ÓÊÕµ½INVITEÇëÇóÆð£¬µ½ÖÕÖ¹INVITE½¨Á¢µÄ¶Ô»°½áÊø£¬¶¼³Æ×÷±»½Ð·½¡£

    Location Service: ¶¨Î»·þÎñ¡£¶¨Î»·þÎñÊÇÓÃÀ´¸øSIPת·¢»òÕß´úÀí·þÎñÆ÷È·¶¨±»½Ð·½¿ÉÄܵÄλÖÃʹÓõġ£Ëü°üº¬Ò»ÕŰó¶¨ÁËaddress-of-recordµÄ±í£¬±»½Ð·½¿ÉÄÜ ÓÐ0µ½¶à¸ö¼Ç¼¡£°ó¶¨µÄ¼Ç¼¿ÉÒÔͨ¹ý¶àÖÖÇþµÀÌí¼ÓºÍɾ³ý£»±¾¹æ·¶¶¨ÒåÁËREGISTER·½·¨À´¸üÐÂ°ó¶¨±í¡£

    Loop£º»·Â·¡£µ±ÇëÇóµÖ´ïÒ»¸ö´úÀí·þÎñÆ÷£¬´úÀí·þÎñÆ÷ת·¢Õâ¸öÇëÇ󣬵±Õâ¸öÇëÇóÔÙ´ÎÀ´µ½Í¬Ò»¸ö´úÀí·þÎñÆ÷£¬¾Í³ÆÖ®Îª»·Â·¡£µ±µÚ¶þ´ÎµÖ´ïµÄʱºò£¬ Request£­URIÖаüº¬ÁËÉϴεִïµÄ×ÊÁÏ£¬²¢ÇÒÓÉÓÚ²¢Ã»ÓÐʲô¶«Î÷¿ÉÒԸıäת·¢µÄ²ßÂÔ£¬ÕâÑù¾Íµ¼ÖÂÕâ¸öÇëÇó»¹»áÔٴα»×ª·¢»ØÀ´¡£»·Â·ÇëÇóÊÇ´íÎóµÄ£¬ ËùÒÔ£¬´¦Àí³ÌÐòÐèÒª¼ì²âºÍ·ÀֹЭÒéÖгöÏֵĻ·Â·ÇëÇó¡£

    Loose Routing:¶ªÊ§Â·ÓÉ¡£´úÀí·þÎñÆ÷ÔÚÏÂÊöÇé¿öÏ»ᶪʧ·ÓÉ¡£
    A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.

    Message:ÏûÏ¢¡£SIPÔªËØÖ®¼ä´«Ë͵ÄЭÒéÊý¾Ý¾ÍÊÇÏûÏ¢¡£SIPÏûÏ¢¼È¿ÉÒÔÊÇÇëÇóÒ²¿ÉÒÔÊÇÓ¦´ð¡£

    Method:·½·¨¡£·½·¨ÊÇÔÚ·þÎñÆ÷ÇëÇó´¦ÀíµÄÖ÷Òª¹¦ÄÜ¡£·½·¨ÊÇÇëÇóÏûÏ¢×ÔÉíЯ´øµÄ¡£µäÐ͵ķ½·¨¾ÍÊÇINVITEºÍBYE¡£

    Outbound Proxy:¶ÔÍâ´úÀí·þÎñÆ÷¡£Ò»¸ö´úÀí·þÎñÆ÷½ÓÊÕµ½¿Í»§µÄÇëÇ󣬼´Ê¹Ëü²»ÊÇÓÉRequest_URIËù¾ö¶¨µÄ·þÎñÆ÷¡£Í¨³£Ò»¸öUA»áÊÖ¹¤ÅäÖÃÒ»¸ö¶ÔÍâµÄ´úÀí·þÎñÆ÷£¬»òÕß¿ÉÒÔͨ¹ýÒ»¸ö×Ô¶¯ÅäÖõÄЭÒé×Ô¶¯ÅäÖÃÒ»¸ö¡£

    Parallel Search: ²¢ÐÐËÑË÷¡£²¢ÐÐËÑË÷Çé¿öÏ£¬´úÀí·þÎñÆ÷»áÏò¶à¸öÓû§¿ÉÄÜ´æÔڵĵط½·¢ÆðÇëÇ󣬲¢ÇҵȴýÓ¦´ð¡£Í¬´®ÐÐËÑË÷²»Í¬µÄµØ·½ÊÇ£¬²¢ÐÐËÑË÷²»»áµÈ´ýÉÏÒ»¸öÇëÇóÓ¦´ð»ØÀ´Ö®ºóÔÙ·¢ÆðÏÂÒ»¸öËÑË÷£¬¶øÊÇÒ»¸ö½ÓÒ»¸öµÄ·¢ÆðËÑË÷ÇëÇó¡£

    Provisional Response: ÁÙʱӦ´ð¡£·þÎñÆ÷ÓÃÀ´±êÖ¾×Ô¼ºÕýÔÚ´¦ÀíµÄÓ¦´ð£¬µ«ÊDZ¾Ó¦´ð²¢²»½áÊøÒ»¸öSIPÊÂÎñ¡£1xxÓ¦´ð¾ÍÊÇÁÙʱµÄ£¬ÆäËûÓ¦´ð±êÖ¾×ÅÊÂÎñµÄ½áÊø¡£

    Proxy,Proxy Server:´úÀí¡¢´úÀí·þÎñÆ÷¡£Ò»¸öÖмäµÄʵÌå¡£Ëü±¾Éí¼´×÷Ϊ¿Í»§¶ËÒ²×÷Ϊ·þÎñ¶Ë£¬ÎªÆäËû¿Í»§¶ËÌṩÇëÇóµÄת·¢·þÎñ¡£Ò»¸ö´úÀí·þÎñÆ÷Ê×ÏÈÌṩµÄÊÇ·ÓÉ·þ Îñ£¬Ò²¾ÍÊÇ˵±£Ö¤ÇëÇó±»·¢µ½¸ü¼Ó¡±¿¿½ü¡±Ä¿±êÓû§µÄµØ·½¡£´úÀí·þÎñÆ÷¶ÔÄ³Ð©Ç¿ÖÆÕþ²ßÓÐÓ㨱ÈÈ磬ȷÈÏÒ»¸öÓû§ÊÇ·ñÔÊÐí½¨Á¢Ò»¸öºô½ÐµÈ£©¡£Ò»¸ö´úÀí·þÎñÆ÷·­ Ò룬²¢ÇÒ£¬Èç¹ûÓÐÐèÒªµÄ»°£¬ÔÙת·¢Ç°»áÖØÐ´ÇëÇóÏûÏ¢¡£

    Recursion£º»ØÂ·¡¢µÝ¹é¡£Ò»¸ö¿Í»§¶Ë£¬ÔÚÏìÓ¦ÇëÇóµÄʱºò²úÉúеĵ½Contract°üÍ·ÓòµÄURIÇëÇóµÄʱºò£¬»áÔÚ3xxÏìÓ¦ÖÐÏÝÈëµÝ¹é¡£ A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.

    Redirect Server:ÖØ¶¨Ïò·þÎñÆ÷¡£Ò»¸öÖØ¶¨Ïò·þÎñÆ÷ÊÇÒ»¸ö²úÉú3xxÓ¦´ðµÄUAS·þÎñÆ÷£¬Ö¸Ê¾¿Í»§¶ËÁ¬½Ó±ðµÄURI¡£

    Registrar: µÇ¼ÇÔ±¡£Ò»¸öµÇ¼ÇÔ±£¨µÇ¼Ç·þÎñÆ÷£©ÊÇÒ»¸ö½ÓÊÕREGISTERÇëÇóµÃ·þÎñÆ÷¡£Ëû°ÑÇëÇóµÃÐÅÏ¢·Åµ½¶¨Î»·þÎñÆ÷ÖУ¬ÕâÑù¿ÉÒÔÈö¨Î»·þÎñÆ÷ºÜ·½±ãµÃ²éÕÒλÖÃÐÅÏ¢¡£

    Regular Transaction:³£¹æÊÂÎñ¡£·²²»°üº¬INVITE,ACK,»òÕßCANCEL·½·¨µÃÊÂÎñ¾ÍÊdz£¹æÊÂÎñ¡£

    Request: ÇëÇó¡£ Ò»¸öÓɿͻ§¶Ë·¢µ½·þÎñ¶ËµÃSIPÐÅÏ¢£¬ÓÃÓÚÖ´ÐÐÌØ¶¨µÃ¹¦ÄÜ¡£

    Response£ºÓ¦´ð¡£Ò»¸öÓÉ·þÎñ¶Ë·¢µ½¿Í»§¶ËµÃSIPÐÅÏ¢¡£ÓÃÀ´±êÖ¾´Ó¿Í»§¶Ë·¢Íù·þÎñ¶ËµÃÇëÇó´¦ÀíµÃÇé¿öµÃ¡£

    Ringback: »ØÁåÒô¡£»ØÁåÒôÊÇÒ»¸öÐźÅÒô¡£ÊǸøºô½Ð·½µÃÒ»¸öÐźűíʾ±»½Ð·½ÕýÔÚÕñÁ壨Ringing£©¡£

    Route Set: ·Óɼ¯¡£Â·Óɼ¯ºÏÊÇÒ»¸ö˳ÐòµÃSIP»òÕßSIPS URI¡£ÕâЩURIÃèÊöÁË´«µÝÒ»¸öÇëÇóËù±ØÐë¾­ÀúµÃ´úÀíÁÐ±í¡£Ò»¸ö·Óɼ¯¿ÉÒÔÊÇ×ÔÊÊÓ¦µÃ£¬ÒòΪ°üÍ·Öаüº¬ÁËRecord-Route(¼Ç¼·ÓÉ)£¬Ò²¿ÉÒÔÊÇÒÀÀµÅäÖõõ½µÃ¡£

    Server£º·þÎñÆ÷¡£Ò»¸öserverÊÇÒ»¸öÍøÂçÔªËØ½ÓÊÕÇëÇó²¢ÇÒ´¦ÀíÇëÇó²¢ÇÒ·¢ËÍ»ØÓ¦¸øÇëÇ󷽡£µäÐ͵÷þÎñÆ÷¾ÍÊÇ´úÀí·þÎñÆ÷£¨proxies£©£¬Óû§´úÀí·þÎñÆ÷£¨user agent servers£©£¬Öض¨Ïò·þÎñÆ÷£¬µÇ¼Ç·þÎñÆ÷¡£

    Sequential Search£ºË³Ðò²éÕÒ¡£ÔÚ˳Ðò²éÕÒÖУ¬´úÀí·þÎñÆ÷˳Ðò³¢ÊÔÁªÏµµØÖ·£¬ÔÚ´¦ÀíÏÂÒ»¸ö֮ǰ±ØÐëµÈ´ýÉÏÒ»¸öÇëÇóÒѾ­ÓÐÒ»¸ö½áÊøÓ¦´ð¡£Ò»¸ö2xx»òÕß6xxϵÁеÃ×îÖÕÓ¦´ð×ÜÊǽáÊøÒ»¸ö˳Ðò²éÕÒ¡£

    Session£º»á»°¡£¸ù¾ÝSDPµÃÃèÊö£º¡±Ò»¸ö¶àýÌå»á»°ÊÇÒ»¸öÓɶàýÌå·¢ËÍ·½ºÍ½ÓÊÜ·½×é³ÉµÃ¼¯ºÏ£¬²¢ÇÒ°üÀ¨ÔÚ·¢ËÍ·½ºÍ½ÓÊÜ·½Ö®¼äµÃÊý¾ÝÁ÷¡£Ò»¸ö ¶àýÌå»áÒéÊÇÒ»¸öµäÐ͵öàýÌå»á»°¡£¡±(RFC 2327[1])(Ò»¸ösessionÔÚSDP¶©Ò»Ï¿ÉÒÔÊÇÒ»¸ö»òÕß¶à¸öRTP sessino)¡£ÔÚ¶¨ÒåÖУ¬Ò»¸ö±»½Ð·½¿ÉÒÔ±»¶à´ÎÑûÇ룬±»²»Í¬µÃºô½Ð·½ÑûÇ룬µ½Í¬Ò»¸ö»á»°¡£ÔÚSDPÖУ¬Ò»¸ö»á»°¿ÉÒÔ±»SDPÓû§Ãû£¬session id,ÍøÂçÀàÐÍ£¬µØÖ·ÀàÐÍ£¬µØÖ·ÔªËصÃÒ»¸ö¼¯ºÏ´®Ëù¹æ¶¨¡£

    SIP ÊÂÎñ£ºÒ»¸öSIPÊÂÎñÊÇÔÚ¿Í»§¶ËºÍ·þÎñ¶ËµÃʼþ£¬°üÀ¨ÁË´ÓµÚÒ»¸öÓɿͻ§¶Ë·¢Ë͵½·þÎñ¶ËµÃÇëÇ󣬵½×îºóÒ»¸ö£¨·Ç1xx£©·þÎñ¶ËÏò¿Í»§¶Ë·¢³öµÃÖÕ½áÓ¦´ð¡£Èç¹û ÇëÇóÊÇÒ»¸öINVITEÇëÇ󣬲¢ÇÒÖÕ½áÓ¦´ðÊÇÒ»¸ö·Ç2xxµÃÓ¦´ð£¬ÄÇôÊÂÎñ»¹°üÀ¨Ò»¸öACK¸ø·þÎñÆ÷×öÓ¦´ð¡£¸øINVITEÇëÇóµÄ2xxÓ¦´ðµÄACK»Ø Ó¦£¬ÊÇÒ»¸ö¶ÀÁ¢µÄÊÂÎñ¡£

    Spiral£º»ØËÝ¡£Ò»¸ö»ØËÝÊÇÖ¸Ò»¸öSIPÇëÇó£¬Â·ÓɸøÒ»¸öproxy£¬²¢ÇÒת·¢£¬µ«ÊÇÓÖ±»Â·ÓÉ»ØÕâ¸öproxy£¬µ«ÊDz»Í¬ÓÚ»ØÂ·£¨µÝ¹é£©µÄÊÇ£¬ Õâ´Î·ÓÉ»ØÀ´µÄÇëÇó°üµÄ°üÍ·ÖУ¬°üº¬Á˲»Í¬ÓÚÔ­ÇëÇóµÄÇëÇó°ü²¿·Ö£¬Ê¹µÃ±¾´Îproxy¾ö¶¨µÄ·ÓÉת·¢ÓëÉϴβ»Í¬¡£Í¨³££¬ÕâÊÇ˵£¬ÇëÇóµÄRequest- URI²»Í¬ÓÚÉϴεÄRequest_URI¡£Ò»¸ö»ØËݲ»ÊÇÒ»¸ö´íÎ󣬲»Í¬ÓÚ»ØÂ·£¨»·Â·loop£©¡£Í¨³£µ¼ÖÂÕâÑùµÄÏÖÏóÊǺô½Ðת·¢£¨call forwarding£©¡£Ò»¸öÓû§ºô½Ðjoe@example.com¡£example.com´úÀí·þÎñÆ÷ת·¢ÇëÇóµ½JoeµÄPC,²¢ÇÒJoeµÄpcºô½Ð ×ªÒÆµ½bob@example.com¡£Õâ¸öÇëÇó±»×ª·¢»Øexample.com´úÀí·þÎñÆ÷¡£¿ÉÊÇÕâ¸ö²¢²»ÊÇÒ»¸ö»·Â·£¨loop£©¡£ÒòΪÇëÇóµÄÄ¿µÄµØÖ·±ä ³ÉÁËÁíÒ»¸öÓû§£¬Õâ¾ÍÊÇ»ØËÝ£¬ÊÇÒ»¸öºÏ·¨µÄÇé¿ö¡£

    Stateful Proxy:ÓÐ״̬µÄ´úÀí·þÎñÆ÷¡£ÔÚÂß¼­ÉÏ£¬ÓÐ״̬µÄ´úÀí·þÎñÆ÷¾ÍÊÇ´¦ÀíÒ»¸öÇëÇóµÄ¹ý³ÌÖУ¬Î¬³ÖµÄÒ»¸ö±¾¹æ·¶Ëù¶¨ÒåµÄ¿Í»§¶ËºÍ·þÎñ¶ËµÄÊÂÎñ״̬»ú¡£Ò²ÊÇÒ» ¸öÊÂÎñÓÖ״̬´úÀí·þÎñÆ÷(transaction stateful proxy)¡£¾ßÌåµÄstateful proxyÔÚµÚ16½Ú¶¨Òå¡£Ò»¸ö£¨ÊÂÎñ£©ÓÐ״̬´úÀí·þÎñÆ÷ºÍÒ»¸öcall stateful proxy²»ÊÇÒ»»ØÊ¡£

    Stateless Proxy£ºÎÞ״̬µÄ´úÀí·þÎñÆ÷¡£ÔÚÂß¼­ÉÏ£¬ÎÞ״̬´úÀí·þÎñÆ÷ÔÚ´¦ÀíÇëÇóÖУ¬²¢²»Î¬³Ö¿Í»§ºÍ·þÎñ¶ËµÄÊÂÎñ״̬»ú¡£Ò»¸öÎÞ״̬µÄ´úÀí·þÎñÆ÷Ö±½Óת·¢Ã¿Ò»¸ö½ÓÊÕµ½µÄÇëÇóºÍÿһ¸ö½ÓÊÕµ½µÄÏìÓ¦¡£

    Strict Routing:Ñϸñ·ÓÉ¡£Â·ÓÉ´¦Àí¹æÔòÈç¹û¸´ºËRFC2543ЭÒ飨and many prior work in progress versions of this RFC£© ¾ÍÊÇÒ»¸öÑϸñ·ÓÉ¡£ÔÚÕâ¸ö¹æÔòÏ£¬Èç¹ûÔÚ°üÍ·Öаüº¬RouteÓò£¬ÄÇô´úÀí·þÎñÆ÷¾Í»áɾ³ýRequest_URIÓòÄÚÈÝ¡£±¾Îĵµ²¢²»ÒªÇóÒ»¶¨ÒªÓÐÑϸñ· ÓÉ£¬±¾ÎĵµÖ»ÒªÇóËÉɢ·ÓɾͿÉÒÔÁË¡£Ö§³ÖÑϸñ·ÓɵĴúÀí·þÎñÆ÷Ò²½ÐÑϸñ·ÓÉÆ÷¡£

    Target Refresh Request: Ä¿±êË¢ÐÂÇëÇó¡£Ò»¸öTarget Refresh RequestÊÇÒ»¸öÔÚ¶Ô»°Öз¢³öµÄÇëÇó£¬ÓÃÀ´¸ü¸Ä¶Ô»°Ä¿±êµÄÇëÇó¡£

    Transaction User(TU):ÊÂÎñÓû§¡£ÔÚtransaction ²ãÖ®ÉϵÄЭÒé²ã¡£TU°üÀ¨ÁËUAC ºËÐÄ£¬UAS core,ºÍproxy core¡£

    Upstream:ÉÏÐÐÁ÷¡£Ò»¸öÔÚÊÂÎñÖеÄÏûÏ¢Á÷Ïò·½Ïò¡£ËüÊÇÖ¸ÓÉÓû§´úÀí·þÎñÆ÷£¨UAS£©·¢³öÓ¦´ðµ½Óû§´úÀí¿Í»§¶Ë£¨UAC£©µÄÏûÏ¢Á÷Ïò·½Ïò¡£

    URL-encoded:Ò»´®¸ù¾ÝRFC2396£­2.4½Ú±àÂëµÄ×Ö·û¡£

    User Agent Client(UAC):Óû§´úÀí¿Í»§¶Ë¡£Óû§´úÀí¿Í»§¶ËÊÇÒ»¸öÂß¼­µÄ¸ÅÄËû´´½¨Ò»¸öÐÂÇëÇ󣬲¢ÇÒÓÿͻ§ÊÂÎñ״̬»ú·¢ËÍÕâ¸öÇëÇó¡£UAC½ÇɫֻÔÚÊÂÎñÖÐ ´æÔÚ¡£»»¾ä»°Ëµ£¬UAC¾ÍÊÇһС¶Î´úÂë³õʼ»¯Ò»¸öÇëÇ󣬲¢ÇÒÔÚÊÂÎñÖÐ×ñÑ­UACµÄ¹æÔò¡£Èç¹ûËü½ÓÏÂÀ´ÊÕµ½Ò»¸öÇëÇó£¬ÄÇôÔÚÄǸöÊÂÎñÖУ¬Ëü¾ÍÊÇ×÷ΪUASÀ´ ´¦ÀíÇëÇó¡£

    UAC Core:UACºËÐÄ¡£ÔÚtransactionºÍtransport²ãÖ®ÉϵÃUACʵÏֵŦÄܼ¯ºÏ¡£

    User Agent Server(UAS): Óû§´úÀí·þÎñÆ÷.UASÊÇÒ»¸öÂß¼­µÄʵÌ壬¶ÔSIPÇëÇó×öÏìÓ¦µÄ¡£Ó¦´ð½ÓÊÜ¡¢¾Ü¾ø¡¢»òÕßת·¢¶ÔÓ¦µÄÇëÇó¡£UAS½ÇÉ«ÔÚÊÂÎñÖдæÔÚ¡£»»¾ä»°Ëµ£¬ÊÇÏìÓ¦ÇëÇóµÄ һС¶ÎÈí¼þ£¬ÔÚÊÂÎñÖÐ×÷ΪUAS´æÔÚ¡£Èç¹ûËû·¢³öÇëÇó£¬ÄÇôËû¾ÍÔÚÊÂÎñÖÐ×÷ΪUAC´æÔÚ¡£

    UAS Core£ºUASºËÐÄ¡£ÔÚtransactionºÍtransport²ãÖÇÉ̵ÄUASʵÏֵŦÄܼ¯ºÏ¡£

    User Agent£¨UA£©¡£Ò»¸öÂß¼­ÊµÌåµÄ¸ÅÄ°üº¬UACºÍUAS¡£
UACºÍUAS£¬¾ÍÏñ´úÀí·þÎñÆ÷ºÍת·¢·þÎñÆ÷£¬ÊÇÔÚÊÂÎñbyÊÂÎñµÄÔ­Àí£¨´®ÐÐÊÂÎñ´¦Àí£©É϶¨ÒåµÄ¡£ÀýÈ磬µ±·¢³öÒ»¸ö³õʼ»¯INVITEÇëÇóµÄʱºò£¬UA×÷ ΪUAC³õʼ»¯Ò»¸öºô½Ð¶¯×÷£¬µ±´Ó±»½Ð·½½ÓÊÕµ½Ò»¸öBYEÇëÇóµÄʱºò£¬UA×÷ΪUASÏìÓ¦¡£ÀàËÆµÄ£¬Í¬ÑùµÄ´úÂë¿ÉÒÔ¶ÔÒ»¸öÇëÇó×öΪproxy·þÎñÆ÷´¦Àí£¬ ¶ÔÁíÒ»¸öÇëÇó×÷ÎªÖØ¶¨Ïò·þÎñÆ÷¡£

    proxy£¬location£¬registrar·þÎñÆ÷¶¼ÊÇÂß¼­ÊµÌ壬ÔÚËüÃǵÄʵÏÖÖУ¬¿ÉÄÜÊÇ×÷Ϊµ¥¸öÓ¦ÓÃʵÏֵġ£
=============================================
The following terms have special significance for SIP.

    Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available.
    Typically, the location service is populated through
registrations. An AOR is frequently thought of as the ¡°public address¡± of the user.

    Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established.         Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.

Rosenberg, et. al. Standards Track [Page 20]

RFC 3261 SIP: Session Initiation Protocol June 2002

    Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation.

    Call Leg: Another name for a dialog [31]; no longer used in this specification.

    Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true.

    Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.

    Conference: A multimedia session (see below) that contains multiple participants.

    Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users.

    Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.

    Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server.

    Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.

    Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields.

    Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a Rosenberg, et. al. Standards Track [Page 21]

RFC 3261 SIP: Session Initiation Protocol June 2002

given header field row are separated by commas. Some header
fields can only have a single header field value, and as a
result, always appear as a single header field row.

Header Field Value: A header field value is a single value; a
header field consists of zero or more header field values.

Home Domain: The domain providing service to a SIP user.
Typically, this is the domain present in the URI in the
address-of-record of a registration.

Informational Response: Same as a provisional response.

Initiator, Calling Party, Caller: The party initiating a session
(and dialog) with an INVITE request. A caller retains this
role from the time it sends the initial INVITE that established
a dialog until the termination of that dialog.

Invitation: An INVITE request.

Invitee, Invited User, Called Party, Callee: The party that
receives an INVITE request for the purpose of establishing a
new session. A callee retains this role from the time it
receives the INVITE until the termination of the dialog
established by that INVITE.

Location Service: A location service is used by a SIP redirect or
proxy server to obtain information about a callee¡¯s possible
location(s). It contains a list of bindings of address-of-
record keys to zero or more contact addresses. The bindings
can be created and removed in many ways; this specification
defines a REGISTER method that updates the bindings.

Loop: A request that arrives at a proxy, is forwarded, and later
arrives back at the same proxy. When it arrives the second
time, its Request-URI is identical to the first time, and other
header fields that affect proxy operation are unchanged, so
that the proxy would make the same processing decision on the
request it made the first time. Looped requests are errors,
and the procedures for detecting them and handling them are
described by the protocol.

Loose Routing: A proxy is said to be loose routing if it follows
the procedures defined in this specification for processing of
the Route header field. These procedures separate the
destination of the request (present in the Request-URI) from

Rosenberg, et. al. Standards Track [Page 22]

RFC 3261 SIP: Session Initiation Protocol June 2002

the set of proxies that need to be visited along the way
(present in the Route header field). A proxy compliant to
these mechanisms is also known as a loose router.

Message: Data sent between SIP elements as part of the protocol.
SIP messages are either requests or responses.

Method: The method is the primary function that a request is meant
to invoke on a server. The method is carried in the request
message itself. Example methods are INVITE and BYE.

Outbound Proxy: A proxy that receives requests from a client, even
though it may not be the server resolved by the Request-URI.
Typically, a UA is manually configured with an outbound proxy,
or can learn about one through auto-configuration protocols.

Parallel Search: In a parallel search, a proxy issues several
requests to possible user locations upon receiving an incoming
request. Rather than issuing one request and then waiting for
the final response before issuing the next request as in a
sequential search, a parallel search issues requests without
waiting for the result of previous requests.

Provisional Response: A response used by the server to indicate
progress, but that does not terminate a SIP transaction. 1xx
responses are provisional, other responses are considered
final.

Proxy, Proxy Server: An intermediary entity that acts as both a
server and a client for the purpose of making requests on
behalf of other clients. A proxy server primarily plays the
role of routing, which means its job is to ensure that a
request is sent to another entity ¡°closer¡± to the targeted
user. Proxies are also useful for enforcing policy (for
example, making sure a user is allowed to make a call). A
proxy interprets, and, if necessary, rewrites specific parts of
a request message before forwarding it.

Recursion: A client recurses on a 3xx response when it generates a
new request to one or more of the URIs in the Contact header
field in the response.

Redirect Server: A redirect server is a user agent server that
generates 3xx responses to requests it receives, directing the
client to contact an alternate set of URIs.

Rosenberg, et. al. Standards Track [Page 23]

RFC 3261 SIP: Session Initiation Protocol June 2002

Registrar: A registrar is a server that accepts REGISTER requests
and places the information it receives in those requests into
the location service for the domain it handles.

Regular Transaction: A regular transaction is any transaction with
a method other than INVITE, ACK, or CANCEL.

Request: A SIP message sent from a client to a server, for the
purpose of invoking a particular operation.

Response: A SIP message sent from a server to a client, for
indicating the status of a request sent from the client to the
server.

Ringback: Ringback is the signaling tone produced by the calling
party¡¯s application indicating that a called party is being
alerted (ringing).

Route Set: A route set is a collection of ordered SIP or SIPS URI
which represent a list of proxies that must be traversed when
sending a particular request. A route set can be learned,
through headers like Record-Route, or it can be configured.

Server: A server is a network element that receives requests in
order to service them and sends back responses to those
requests. Examples of servers are proxies, user agent servers,
redirect servers, and registrars.

Sequential Search: In a sequential search, a proxy server attempts
each contact address in sequence, proceeding to the next one
only after the previous has generated a final response. A 2xx
or 6xx class final response always terminates a sequential
search.

Session: From the SDP specification: ¡°A multimedia session is a
set of multimedia senders and receivers and the data streams
flowing from senders to receivers. A multimedia conference is
an example of a multimedia session.¡± (RFC 2327 [1]) (A session
as defined for SDP can comprise one or more RTP sessions.) As
defined, a callee can be invited several times, by different
calls, to the same session. If SDP is used, a session is
defined by the concatenation of the SDP user name, session id,
network type, address type, and address elements in the origin
field.

SIP Transaction: A SIP transaction occurs between a client and a
server and comprises all messages from the first request sent
from the client to the server up to a final (non-1xx) response

Rosenberg, et. al. Standards Track [Page 24]

RFC 3261 SIP: Session Initiation Protocol June 2002

sent from the server to the client. If the request is INVITE
and the final response is a non-2xx, the transaction also
includes an ACK to the response. The ACK for a 2xx response to
an INVITE request is a separate transaction.

Spiral: A spiral is a SIP request that is routed to a proxy,
forwarded onwards, and arrives once again at that proxy, but
this time differs in a way that will result in a different
processing decision than the original request. Typically, this
means that the request¡¯s Request-URI differs from its previous
arrival. A spiral is not an error condition, unlike a loop. A
typical cause for this is call forwarding. A user calls
joe@example.com. The example.com proxy forwards it to Joe¡¯s
PC, which in turn, forwards it to bob@example.com. This
request is proxied back to the example.com proxy. However,
this is not a loop. Since the request is targeted at a
different user, it is considered a spiral, and is a valid
condition.

Stateful Proxy: A logical entity that maintains the client and
server transaction state machines defined by this specification
during the processing of a request, also known as a transaction
stateful proxy. The behavior of a stateful proxy is further
defined in Section 16. A (transaction) stateful proxy is not
the same as a call stateful proxy.

Stateless Proxy: A logical entity that does not maintain the
client or server transaction state machines defined in this
specification when it processes requests. A stateless proxy
forwards every request it receives downstream and every
response it receives upstream.

Strict Routing: A proxy is said to be strict routing if it follows
the Route processing rules of RFC 2543 and many prior work in
progress versions of this RFC. That rule caused proxies to
destroy the contents of the Request-URI when a Route header
field was present. Strict routing behavior is not used in this
specification, in favor of a loose routing behavior. Proxies
that perform strict routing are also known as strict routers.

Target Refresh Request: A target refresh request sent within a
dialog is defined as a request that can modify the remote
target of the dialog.

Transaction User (TU): The layer of protocol processing that
resides above the transaction layer. Transaction users include
the UAC core, UAS core, and proxy core.

Rosenberg, et. al. Standards Track [Page 25]

RFC 3261 SIP: Session Initiation Protocol June 2002

Upstream: A direction of message forwarding within a transaction
that refers to the direction that responses flow from the user
agent server back to the user agent client.

URL-encoded: A character string encoded according to RFC 2396,
Section 2.4 [5].

User Agent Client (UAC): A user agent client is a logical entity
that creates a new request, and then uses the client
transaction state machinery to send it. The role of UAC lasts
only for the duration of that transaction. In other words, if
a piece of software initiates a request, it acts as a UAC for
the duration of that transaction. If it receives a request
later, it assumes the role of a user agent server for the
processing of that transaction.

UAC Core: The set of processing functions required of a UAC that
reside above the transaction and transport layers.

User Agent Server (UAS): A user agent server is a logical entity
that generates a response to a SIP request. The response
accepts, rejects, or redirects the request. This role lasts
only for the duration of that transaction. In other words, if
a piece of software responds to a request, it acts as a UAS for
the duration of that transaction. If it generates a request
later, it assumes the role of a user agent client for the
processing of that transaction.

UAS Core: The set of processing functions required at a UAS that
resides above the transaction and transport layers.

User Agent (UA): A logical entity that can act as both a user
agent client and user agent server.

The role of UAC and UAS, as well as proxy and redirect servers, are
defined on a transaction-by-transaction basis. For example, the user
agent initiating a call acts as a UAC when sending the initial INVITE
request and as a UAS when receiving a BYE request from the callee.
Similarly, the same software can act as a proxy server for one
request and as a redirect server for the next request.

Proxy, location, and registrar servers defined above are logical
entities; implementations MAY combine them into a single application

ǰһƪ£ºThe seq_file interface
Ç×£¬Äú»¹Ã»ÓеǼ,Çë[µÇ¼]»ò[×¢²á]ºóÔÙ½øÐÐÆÀÂÛ